Quantcast
Channel: プログラマのはしくれダイアリー
Viewing all 398 articles
Browse latest View live

いまだにAPTって言葉使ってるの日本人だけっぽい

$
0
0








 はじめに



皆さんはAPTって言葉聞いたことありませんか?

Dagger2、Android Annotations、Lombokとかああいったものを使う時に
一緒に使われるシーンがあるようです。


APTって何気なく使っている方が多くて、なんとなくひっかかりました。
APTそのものをちゃんと説明している人は少ないなーって。



APTってAnnotation Processing Toolを略したものなんですが、
この用語を使ってるのってどうやら日本人だけっぽいです。

もう少し具体的に言うと、英語圏では使われていない。
試しに、Googleで「APT Java」で検索してみましょう。出てくるのは日本人の記事ばかりです。

検索するLocaleを英語だけにするとAPT Javaでは何も出てこない。
というか、今その言葉を使っている人はいないようです。



「Annotation Processing Java」とかで英語記事だけ検索して
100サイトの内容を確認しましたが、その中でAPTって使っているのは7記事ぐらいでした。
つまり、「アノテーションでコンパイル時にええ感じにしてくれるやつ」を
APTって言ってるのは7%(僕調べ)。。


ってことで、言いたいのは古い言葉使うのやめませんか?ってことです。
…といいつつ、僕も何も考えず使ってたんですけどね(- -;)




 APTってJava SE 5だよ?



そう、Java SE 5です。しかも非標準でした。
そもそも、APTって大文字表記もなんかおかしい感じで、
aptってコマンドが由来で、aptというツールだったようです。
コマンドを実現させるAnnotation ProcessingのAPIがcom.sun.mirrorというパッケージの
Mirror APIというものでした。



普段新しいもの追いかけて、「Java 1.5とかw」って言ってるのに
APTって言葉使い続けるのダッサイなと個人的には思います(ブーメラン)。


参考
注釈処理ツール (apt) 入門



 APTってJava SE 6で死んだよ?



Mirror APIのjavadocにもさりげなく
「apt ツールとそれに関連する API は、将来の J2SE リリースで変更または置き換えられる可能性があります。」
と書いてありましたが、あっさりJava SE 6で更に高機能のAPIが提供されるようになりました。


そして、javacコマンドでAnnotation Processingは出来るようになり、
「aptコマンドとは一体何だったのか」という状態になりました。
これが今主流のPluggable Annotation Processing API(JSR 269)です。


さらにJava SE 7でMirror APIは非推奨となりました。
Java SE 8では削除されています。


ココらへんに書いてあります。

http://www.wakhok.ac.jp/~tatsuo/summer2006/6th/
http://docs.oracle.com/javase/jp/7/technotes/guides/apt/index.html
http://www.oracle.com/technetwork/jp/java/javase/overview/8-compatibility-guide-2156366-ja.html


 Pluggable Annotation Processing API



Pluggable Annotation Processing APIに関しては櫻庭さんの記事を呼んでおけば間違いないと思います笑
Java技術最前線ITpro -「Java SE 6完全攻略」第94回 アノテーションを処理する その1

Javaで注釈処理をするスタンダードとなるAPIとしてJSR 269で仕様が決定されました。



 本来どう呼ぶべきか



Java SE5で一瞬で消えてしまってAPTという言葉が広まったのが諸悪の根源な気がします。
そして、「Pluggable Annotation Processing」という言葉があまり認知されていないのかな…。
キャッチーさが足りなかったのか。

アノテーションプロセッサとか呼んでおくと間違いないと思います。

英語圏のサイトを100サイト眺めた個人的統計としては、Annotation Processorか
Annotation Processingって言葉がよく用いられています。


ということで、APTは使わずアノテーションプロセッサと呼びましょう、って感じで
一応結論は出たんですが、なんでAPTって言葉が出回っているのか
ちょっともやもやが残ります。

そもそもAPTは何でAnnotation Processorは何をするものなのか。

APTはaptというJavaの非標準ツールのコマンド。
今現在、Annotation Processorと呼ばれているのはPluggable Annotation Processing(JSR 269)で
aptのMirror APIに対して互換性を持って同等の機能を提供します。
Mirror APIはPluggable Annotation Processingに置き換わったという文言もありました。
詳しくはJSR呼んでみてください。


ってことはaptの2代目ってことでもあるのかな…とか思ったりもするわけですが、
aptコマンドが使われずにjavacコマンドに統合された今、プロセッサーAPIだけが残っている状態。
それはもはや「ツール」ではないのでやっぱ不自然ですよね。

「APTで動く」ではなくて「javacオプションで注釈処理が出来る」の方がしっくりきます。多分。




 Annotation Processorは何をするものなのか


1つ気になったのは、Annotation Processorが結局のところ、何をやるものなのかというところです。
基本的な使われ方としてはボイラープレートコードの削減としてアノテーションを書き、
アノテーションプロセッサにコンパイル時に読み込ませてよしなにしてもらうということなんだと思います。

で、気になったのがJavaのソースコードを出力するものをAnnotation Processingとしているのか、どうなのか。
lombokに関してはソースコードを出力するわけではなく、AST(抽象構文木)をいじるので
クラスファイルをいじるということになります。

これってAnnotation Processing、古くはapt的な範疇なのかなぁという。


で、Annotation Processor関連のjavadocとかを調べると、
Javaのソースコードを出力することを想定して設計されているとのことです。

lombokはPluggable Annotaton Processing APIを内部で使っているのですが、
ちょっと微妙なところですねー。。。





 まとめ



APTという用語について色々と調べて書いてみました。


簡単にまとめると以下の様な感じです。


・APTって言ってるのは日本人だけ
・海外ではAnnotaton ProcessingとかAnnotation Processorとか言われてる
・Java SE 5 でaptは出来た
・Java SE 6 でPluggable Annotation Processingが出来てaptは使われなくなった
・Java SE7 でaptは非推奨になった
・Java SE8 でaptは削除された
・日本でもアノテーションプロセッサとか言っておこう


自分の使う言葉の定義は重要ですね!(ブーメラン)


ということで、自分のモヤモヤとか知識のなさはある程度
改善されました。


なんかアノテーションプロセッサでいい感じのもんを作りたいぞ!




Java SEのパッケージを独断と偏見だけで断捨離する

$
0
0




 はじめに





Javaの歴史も20年。
脈々と後方互換が守られてバージョンが上がってるわけですが、
ライブラリも豊富になっていき、覚えることも増えてきている気がします。

だけど、逆に今さら覚えなくても良いものもたくさんあるんじゃないか。
という疑問が浮かんできました。


それに加えて、個人的なことだけど、
Javaの色々を調べるうちにだんだんJavaが分からなくなった。
ので、全体図を俯瞰してみたくなりました。

ということで、Java SE のパッケージを眺めるのが良いかと思い、
それぞれ見ていくことにします。



とりあえず、JDKの中身をあさってみます。





 対象



Oracleのjdk 1.8.0_40



 それぞれの構成



javadocで提供されているのは

・orgパッケージ
・javaパッケージ
・javaxパッケージ

http://docs.oracle.com/javase/jp/8/docs/api/

src.zipに含まれているのは

・comパッケージ
・javaパッケージ
・javaxパッケージ
・launcherパッケージ
・orgパッケージ



rt.jarに含まれているのは

・comパッケージ
・javaパッケージ
・javaxパッケージ
・jdkパッケージ
・orgパッケージ
・sunパッケージ
(あとMETA-INF)





 どこ見るか



基本的にはjavadocで提供されているものを使えって感じで良いと思います。



 src.zipとrt.jarで中身違う?



src.zipとrt.jarでsunパッケージがあったり無かったりするのは
ソースコード(.javaや.h)ファイルをどこまで提供するかって話だと思います。
runtimeではinternalに使ってるのかな。

と思ったけど、Oracleのサイトにsrc.zipについて説明があった


src.zipはJavaプログラミング言語のソースのJavaコアAPIを構成するすべてのクラス用のファイル
(つまり、 Java用のソース。java.*、javax。およびいくつかのorg.*。com.sun.*を除いた) 。
このソースコードは、開発者がJavaを学ぶのとJavaを利用するのを補助する目的のみです。
これらのファイルは、プラットフォーム固有の実装コードは含まれていませんし、
クラスライブラリを再構築するために使用することはできません。
http://www.oracle.com/technetwork/java/javase/jdk-7-readme-429198.html

ただ、com.sunもsrc.zipにちょっと含まれているので謎だ。。

ちなみにsrc.zipに含まれているlaunchにはjavaの実行時に使われているC言語っぽいものがあった。
.hファイルとかだし、多分。






 javadocから絞る



ということで、
・orgパッケージ
・javaパッケージ
・javaxパッケージ
を知ってればまぁ良い気がします。


各パッケージを眺めた結果も書いておきます。
※長いので、最下部に掲載。



 最小セット



最終的に必須と判断したのは


・java.io
・java.lang
・java.lang.reflect
・java.math
・java.nio
・java.nio.charset
・java.nio.charset.spi
・java.nio.file
・java.nio.file.attribute
・java.nio.file.spi
・java.text
・java.time
・java.time.format
・java.util
・java.util.function
・java.util.regex
・java.util.stream
・javax.annotation



それ以外も、もちろん捨てがたいというか知っておくべきものもたくさんあるけど、
JavaのAPIを最小限必要なものに絞ってみるとこんな感じな気がする。
あと、単純にパッケージで区切れるものでもないし、OSSライブラリ使ったり
することに確実になるので、微妙なところではあります。


また、パッケージ単位でしか見てないので、
パッケージの中にはdeperecatedなクラスも混ざってたり…、
とかそこら辺は全然ノーチェックです。。。


 必要に応じて学ぶ



思い切って削ったのはアプレット、awt、swing、RMI、CORBA。
アプレットはJava登場した初期こそもてはやされたけど、
現在だと脆弱性見つかったりとか、そもそも使わないと思います。
デスクトップアプリケーションはawtやswingとか使わず、JavaFXでやろう(で良いと思う。)





 2015/05/31追記その1


ご意見いただきました。








java.awtをアプレットを使わないからという理由で
バッサリ切るのは違うみたいですね。
awtパッケージにはアプレット関連以外でも色々なライブラリがあります。
そこらへんJavaFXで全部網羅されてないかなぁとか
テキトーなことを思ってたんですが、そういうわけでもなく。
そもそも「アプレットはもう使わない」から「java.awtパッケージは使わない」ってのは
論理的ではないですね_(:3」∠)_


JavaFXがヘッドレスで動かない。ヘッドレスというのはキーボードとかマウスとかを
接続しないでマウス操作、キーボード操作をするってことですね、おそらく。

確かに、java.awtパッケージにはマウス操作とかキーボード操作用のAPIがあります。


(追記その1ここまで)


・・・・・・・・・・・・・・

 ヘッドレス環境について(2015/06/02追記)



またまた、きしださんにコメントいただきました。
ヘッドレスはグラフィックカードが無い状態をイメージすると良いと。
なるほど、なんとなく分かってきました笑
グラフィックとかがJavaFXでは生成出来ないってかんじですかね。。

java.awtではヘッドレスモードみたいなものがあって設定で選択出来るようです。

櫻庭さんが以前に書いていたみたいですね。

Features of Java2 SDK, Standard Edition, v1.4 - Java in the Box





 RMI、CORBAとかその他に関して



RMI、CORBAに関してもJavaのサーバーサイドだとEJBがその代りをするのではないでしょうか。
古いシステムとかで言語関係なくシステム連携するという縛りがあれば使うかもしれないけど。



CORBA関連のJava技術について - 達人プログラマーを目指して




Concurrency Utilities、XML操作(DOM、SAX、StAX)、JAX-WS、SOAP、JAXB、
セキュリティ関連、暗号化、ImageI/Oなどなどは要件によっては使う必要が出てくるので、
必要に応じて。






JDBC部分もあまり触らないとは思うけど、解析したり
するとき当然根幹になるから知っとくべきだと思います。


MIDIとかSound系とかはなかなか使わんだろうなぁ。


 2015/05/31追記その2



しんさんがこの辺りに対してコメントくれてるんですけど、
面白いなぁと思います。


動くアプリケーションとかゲームとか目線でお話されてるんだと思います。
僕はエンプラっていうかサーバーサイドのJavaとかなんかところを起点に
優先順位を考えてるので、取捨選択も違うなぁと。
こんな記事書いてますが、そんな簡単に捨てられるものでもないしなぁ…笑




(追記その2ここまで)


・・・・・・・・・・・・・・


 その他参考


Java技術最前線
Reader/Writer/InputStream/OutputStream - 裏紙
JJUGのエキスパートが語るエンタープライズ・アーキテクチャの過去、現在、未来──SOAP・RESTからIoT・ウェアラブルまで
Javaメモ目次(Hishidama's Java Memo)


 雑な一覧



ホントに個人的に分類してみました。
今後、ツッコミがあったりとか必要性を感じたら修正していきます。多分。

2015/05/31にツッコミを受けて、java.awtのところを修正してます。
かなりざっくりな修正。知識なくてスミマセン…。



個人的な指標値
1.必須
2.知っておくべき
3.必要に応じて
4.古い技術だが必要に応じて
5.特殊な機能
6.今後使わないだろうもの






  javaパッケージ





番号javaパッケージ備考 since優先度
1 java.ioIO操作の基本1.0 1
2 java.lang javaの基本1.0 1
3 java.lang.reflectリフレクション1.1 1
4 java.math算術計算 1.1 1
5 java.nio Buffer処理 1.4 1
6 java.nio.charset charset関連1.4 1
7 java.nio.charset.spi charset関連1.4 1
8 java.nio.fileNew I/O 2 1.7 1
9 java.nio.file.attribute New I/O 2 1.7 1
10java.nio.file.spi New I/O 2 1.7 1
11java.textテキスト操作 1.1 1
12java.time Date and Time1.8 1
13java.time.format Date and Time1.8 1
14java.utilユーティリティ1.0 1
15java.util.function関数インターフェース 1.8 1
16java.util.regex正規表現 1.4 1
17java.util.stream Stream API1.8 1
18java.nio.channelsチャネル操作1.4 2
19java.nio.channels.spi NIO1.4 2
20java.text.spiテキスト操作 1.6 2
21java.time.chrono Date and Time1.8 2
22java.time.temporalDate and Time1.8 2
23java.time.zone Date and Time1.8 2
24java.util.concurrent Concurrency Utilities1.5 2
25java.util.concurrent.atomic Concurrency Utilities1.5 2
26java.util.concurrent.locksConcurrency Utilities1.5 2
27java.util.loggingロギング 1.4 2
28java.util.spiユーティリティのサービスプロバイダ 1.6 2
29java.netネットワーク関連 1.0 3
30java.securityセキュリティ関連 1.1 3
31java.security.aclセキュリティ関連 1.1 3
32java.security.certセキュリティ関連1.2 3
33java.security.interfaces RSA 1.1 3
34java.security.specセキュリティ関連1.2 3
35java.util.zipzip1.1 3
36java.lang.annotationアノテーション関連の定義 1.5 4
37java.lang.instrument JVMの計測 1.5 4
38java.lang.management JMXとか1.5 4
39java.sql SQL 1.1 4
40java.util.prefs KVS(キーバリューストア) 1.4 4
41java.lang.invoke invoke dynamic関連 1.7 5
42java.lang.refGCと対話するとき。1.2 5
43java.util.jarJAR操作1.2 5
44java.appletアプレットは今後使わない 1.0 6
45java.awtヘッドレス環境での操作などJavaFXで賄えないものは使う 1.0 4
46java.awt.color JavaFXで賄えないものは使う 1.2 4
47java.awt.datatransferJavaFXで賄えないものは使う 1.1 4
48java.awt.dnd JavaFXで賄えないものは使う 1.2 4
49java.awt.event JavaFXで賄えないものは使う 1.1 4
50java.awt.fontJavaFXで賄えないものは使う 1.2 4
51java.awt.geomJavaFXではJava2Dは大体出来ないので使う 1.2 4
52java.awt.im JavaFXで賄えないものは使う 1.2 4
53java.awt.im.spi JavaFXで賄えないものは使う 1.3 4
54java.awt.image JavaFXで賄えないものは使う 1.2 4
55java.awt.image.renderable JavaFXで賄えないものは使う 1.2
56java.awt.print JavaFXで賄えないものは使う 1.2 4
57java.beansJavaBeansの死活管理?でもあんまり使わないと思う 1.2 5
58java.beans.beancontext JavaBeansの死活管理?でもあんまり使わないと思う 1.2 5
59java.rmi RMI 1.1 6
60java.rmi.activation RMI起動1.2 6
61java.rmi.dgc RMIのGC 1.1 6
62java.rmi.registry RMIレジストリ 1.1 6
63java.rmi.server RMIのサーバ側 1.1 6


  javaxパッケージ





番号javaxパッケージ備考since優先度
64javax.imageioImageI/O 1.4 2
65javax.imageio.event ImageI/O 1.4 2
66javax.imageio.metadata ImageI/O 1.4 2
67javax.imageio.plugins.bmp ImageI/O 1.5 2
68javax.imageio.plugins.jpegImageI/O 1.4 2
69javax.imageio.spi ImageI/O 1.4 2
70javax.imageio.stream ImageI/O 1.4 2
71javax.crypto暗号化関連1.4 3
72javax.crypto.interfaces暗号化関連1.4 3
73javax.crypto.spec暗号化関連1.4 3
74javax.naming JNDI関連 1.3 3
75javax.naming.directory JNDI関連 1.3 3
76javax.naming.eventJNDI関連 1.3 3
77javax.naming.ldap JNDI関連 1.3 3
78javax.naming.spi JNDI関連 1.3 3
79javax.netネットワーク(ソケット通信) 1.4 3
80javax.net.sslネットワーク(ソケット通信) 1.4 3
81javax.security.authセキュリティ関連 1.4 3
82javax.security.auth.callback認証コールバック 1.4 3
83javax.security.auth.kerberosケルベロス認証 1.4 3
84javax.security.auth.loginログイン認証 1.4 3
85javax.security.auth.spiサービスインターフェース 1.4 3
86javax.security.auth.x500 x500プリンシパル1.4 3
87javax.security.cert公開鍵 1.4 3
88javax.security.sasl SASL 1.5 3
89javax.transaction.xa JTAトランザクション 1.4 3
90javax.xml.namespace XML関連不明3
91javax.xml.parsers DOMとSAX不明3
92javax.xml.stream XML関連不明3
93javax.xml.stream.events XML関連不明3
94javax.xml.stream.utilXML関連不明3
95javax.xml.transform XML関連不明3
96javax.xml.transform.dom XML関連不明3
97javax.xml.transform.sax XML関連不明3
98javax.xml.transform.stax StAX 1.6 3
99javax.xml.transform.streamXML関連不明3
100 javax.xml.validation XML関連不明3
101 javax.accessibilityアクセスルール 1.2 4
102 javax.activation SOAP不明4
103 javax.jws SOAP 1.6 4
104 javax.jws.soap SOAP 1.6 4
105 javax.lang.model SOAP 1.6 4
106 javax.lang.model.element SOAP不明4
107 javax.lang.model.typeSOAP 1.6 4
108 javax.lang.model.utilJMX 1.5 4
109 javax.management JMX 1.5 4
110 javax.management.loading JMX 1.5 4
111 javax.management.modelmbean JMX 1.5 4
112 javax.management.monitor JMX 1.5 4
113 javax.management.openmbeanJMX 1.5 4
114 javax.management.relation JMX 1.5 4
115 javax.management.remote JMX 1.5 4
116 javax.management.remote.rmi JMX 1.5 4
117 javax.management.timer JMX 1.5 4
118 javax.print印刷API1.4 4
119 javax.print.attribute印刷API1.4 4
120 javax.print.attribute.standard印刷API1.4 4
121 javax.print.event印刷API1.4 4
122 javax.sql SQL 1.4 4
123 javax.sql.rowset SQL不明4
124 javax.sql.rowset.serial SQL不明4
125 javax.sql.rowset.spi SQL不明4
126 javax.xml JAXB不明4
127 javax.xml.bind JAXB不明4
128 javax.xml.bind.annotation JAXB不明4
129 javax.xml.bind.annotation.adaptersJAXB不明4
130 javax.xml.bind.attachment JAXB不明4
131 javax.xml.bind.helpers JAXB不明4
132 javax.xml.bind.util JAXB不明4
133 javax.xml.crypto XML暗号化 1.6 4
134 javax.xml.crypto.dom XML暗号化 1.6 4
135 javax.xml.crypto.dsigXML暗号化 1.6 4
136 javax.xml.crypto.dsig.dom XML暗号化 1.6 4
137 javax.xml.crypto.dsig.keyinfoXML暗号化 1.6 4
138 javax.xml.crypto.dsig.specXML暗号化 1.6 4
139 javax.xml.datatypeXML関連不明4
140 javax.xml.soap SOAP不明4
141 javax.xml.ws JAX-WS不明4
142 javax.xml.ws.handler JAX-WS不明4
143 javax.xml.ws.handler.soap JAX-WS不明4
144 javax.xml.ws.http JAX-WS不明4
145 javax.xml.ws.soap JAX-WS不明4
146 javax.xml.ws.spi JAX-WS不明4
147 javax.xml.ws.spi.httpJAX-WS不明4
148 javax.xml.ws.wsaddressing JAX-WS不明4
149 javax.xml.xpath JAX-WS 1.5 4
150 javax.annotation PostConstructとか不明5
151 javax.annotation.processing Pluggable Annotation Processing API 1.6 5
152 javax.scriptスクリプトエンジン 1.6 5
153 javax.sound.midi MIDI 1.3 5
154 javax.sound.midi.spi MIDI 1.3 5
155 javax.sound.sampledサウンド 1.3 5
156 javax.sound.sampled.spiサウンド 1.3 5
157 javax.tools Compiler操作など 1.6 5
158 javax.activity ORBの例外 1.5 6
159 javax.rmi RMI IIOP不明6
160 javax.rmi.CORBA RMI CORBA不明6
161 javax.rmi.sslSSL 1.5 6
162 javax.swing Swingは今後使わない 1.2 6
163 javax.swing.border同上 1.2 6
164 javax.swing.colorchooser同上 1.2 6
165 javax.swing.event同上 1.2 6
166 javax.swing.filechooser同上 1.2 6
167 javax.swing.plaf同上 1.2 6
168 javax.swing.plaf.basic同上 1.2 6
169 javax.swing.plaf.metal 同上 1.2 6
170 javax.swing.plaf.multi同上 1.2 6
171 javax.swing.plaf.nimbus同上 1.7 6
172 javax.swing.plaf.synth同上 1.2 6
173 javax.swing.table同上 1.2 6
174 javax.swing.text同上 1.2 6
175 javax.swing.text.html同上 1.2 6
176 javax.swing.text.html.parser同上 1.2 6
177 javax.swing.text.rtf同上 1.2 6
178 javax.swing.tree同上 1.2 6
179 javax.swing.undo同上 1.2 6
180 javax.transaction ORBトランザクション 1,3 6


  orgパッケージ






番号orgパッケージ備考since優先度
181 org.w3c.dom DOM不明3
182 org.w3c.dom.bootstrapDOM不明3
183 org.w3c.dom.eventsDOM不明3
184 org.w3c.dom.ls DOM不明3
185 org.w3c.dom.views DOM不明3
186 org.xml.sax SAX不明3
187 org.xml.sax.ext SAX不明3
188 org.xml.sax.helpers SAX不明3
189 org.ietf.jgssセキュリティ関連 1.4 5
190 org.omg.CORBA古いシステムでもない限りは不要。 1.2 6
191 org.omg.CORBA.DynAnyPackage同上 1.2 6
192 org.omg.CORBA.ORBPackage同上 1.2 6
193 org.omg.CORBA.portable同上 1.2 6
194 org.omg.CORBA.TypeCodePackage同上 1.2 6
195 org.omg.CORBA_2_3同上 1.3 6
196 org.omg.CORBA_2_3.portable同上 1.3 6
197 org.omg.CosNaming同上 1.3 6
198 org.omg.CosNaming.NamingContextExtPackage同上 1.4 6
199 org.omg.CosNaming.NamingContextPackage同上 1.4 6
200 org.omg.Dynamic同上 1.4 6
201 org.omg.DynamicAny同上 1.4 6
202 org.omg.DynamicAny.DynAnyFactoryPackage同上 1.4 6
203 org.omg.DynamicAny.DynAnyPackage同上 1.4 6
204 org.omg.IOP同上 1.4 6
205 org.omg.IOP.CodecFactoryPackage同上 1.4 6
206 org.omg.IOP.CodecPackage同上 1.4 6
207 org.omg.Messaging同上 1.4 6
208 org.omg.PortableInterceptor同上 1.4 6
209 org.omg.PortableInterceptor.ORBInitInfoPackage同上 1.4 6
210 org.omg.PortableServer同上 1.4 6
211 org.omg.PortableServer.CurrentPackage同上 1.4 6
212 org.omg.PortableServer.POAManagerPackage同上 1.4 6
213 org.omg.PortableServer.POAPackage同上 1.4 6
214 org.omg.PortableServer.portable同上 1.4 6
215 org.omg.PortableServer.ServantLocatorPackage同上 1.4 6
216 org.omg.SendingContext同上 1.3 6
217 org.omg.stub.java.rmi同上 1.3 6





   まとめ



今回はJavaのパッケージの中で必要なもの、必要でないものを考えてみました。
また、必要なものに関しても優先度の指標値を個人的につけてみました。
なにか具体的に根拠のあるものでもなく、完全に主観です。

なので、ツッコミしてもらえれば考え直すこともいっぱい出てくるだろうなぁ。。

こういう、暇人な作業してたおかげで、ちょっとだけどこに何があるかとか
こんなクラスがあるんだ〜とか勉強になりました!





JavaエンジニアのためのJavaScript資料を目指して色々

$
0
0






 はじめに



プログラマの中には何故かJavaScriptを避けたがる人がいるように思います。

フロントエンドのマルチブラウザ環境や
変化の早さ、テストの難しさなどを敬遠しているのかなと思っています。

[JavaFX] Why, Where, and How JavaFX Makes Sense

だけど、個人的には言語だけ見るとそんな必要もないなと思うのです。
JavaScriptは素直で便利なやつだと思ってます。


そこで、今回はJavaエンジニアに贈るJavaScriptについて、
という気持ちを込めて記事を書きます笑






 前提



なんちゃってJavaScript使いなので、正しくない部分もあると思います。
また、ブラウザ上での操作を想定しています。
「普段Javaやってる僕がJavaScriptを調べてみた」ぐらいの内容と思ってください。


僕がどのぐらい普段JavaScript書いているかというと、
たまにajax処理とかUIの描画操作とかイベントハンドリングとかを
JavaScriptでやってcallbackヘルに悩ませられるレベルです。



 基本的なところ



  • ECMAScript
  • エクマスクリプトと読むらしい。
    JavaScriptの標準仕様とされています。
    現在はECMAScript5が最新。ECMAScript6策定中。
    ECMAScript4は放棄されたので、古い環境(具体的にはIE8とか…)
    だとECMAScript 3っぽいです。で、僕の知識もECMAScript 3ぐらい。。

    http://ja.wikipedia.org/wiki/ECMAScript
    http://kangax.github.io/compat-table/es5/


  • ブラウザのWeb API DOM
  • documentやconsoleといったオブジェクトはDOMの仕様に則って、
    ブラウザが提供しているAPIということだと思っています。
    それをJavaScriptから使っている、ということ。多分。

  • JavaScriptにはクラスが無い。

  • JavaScriptはクラスベースのオブジェクト指向ではないです。
    オブジェクトが色んなものを構築しているシンプルな言語だと思います。
    (クラス構文を用意する流れは各所であります)


Javaのやり方がJavaScriptで出来ないっていうのは根本的に違っていて、
JavaとクラスとJavaにおけるオブジェクト指向のことは忘れて
頭をクリアにして学んだほうが良いように思います。


それを踏まえて、Javaを普段使っているような人は
Javaだったらこういう手法でこういう目的があるけど
JavaScriptだとやり方わかんないなってなると思うので、
つらつら書いて整理してみることにします。



 標準グローバルオブジェクト(カテゴリ別)



Javaで言うところのjava.langパッケージみたいな。どっからでもつかえるやつ。
各種類ごとに見ていきます。


とりあえずここらへん抑えておけばいいだろう、っていう
僕のお得意な発想です。


汎用コンストラクタ



  • Array
  • Boolean
  • Date
  • Function
  • Iterator
  • Number
  • Object
  • RegExp
  • String
  • Proxy
  • ParallelArray


よく使うのはObject、Array、Dateとかですかね…。
ただ、Dateに関してはブラウザの日時(クライアント側の日時)なので、
システム日付とか呼ばれるものを利用する場合には
サーバー側から取得する必要があります。


非コンストラクタ関数

  • encodeURI
  • eval
  • isNaN
  • parseFloat
  • parseInt
  • uneval


このあたりもよく使う関数ですね。


2015/06/07追記


evalを使うことはあまり推奨されていません。
文字列を関数として実行するものなので、悪意のあるインジェクションとか
気にしないとダメってことですね。


https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/eval

その他

  • Infinity
  • Intl
  • JSON
  • Math
  • NaN
  • undefined
  • null


JSONとかはECMAScript 5からです。。。


2015/06/07追記

ECMAScript 5なんですが、ブラウザによってはJSONをサポートしているものもあります。
ECMAScript 5 compatibility table

もろもろ詳しくは下記参照ということで。

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects



 グローバルオブジェクト


このあたりを覚えておくと良いと思います。
JavaScriptというよりはWebのAPIなところですが。。

  • window
  • ブラウザウィンドウの情報を持つ
  • (window.)document
  • DOM操作のための情報をもつ
  • console
  • ログ出力用のオブジェクト
  • (window.)parent
  • 親ウィンドウの情報をもつ
  • (window.)opener
  • ウィンドウを開いたウィンドウの情報を持つ


 グローバルオブジェクトの関数



このあたりも、説明するまでもないかなぁという感じです。
  • (window.)alert
  • ウィンドウアラート表示
  • (window.)open
  • 別ウィンドウ表示
  • (window.)close
  • ウィンドウを閉じる
  • (window.)confirm
  • 承認ウィンドウ表示
  • (window.)document.createElement
  • DOMエレメント作成
  • (window.)document.getElementById
  • idでDOMエレメント取得
  • (window.)document.getElementsByName
  • nameでDOMエレメント取得
  • (window.)document.getElementsByTagName
  • tag名でDOMエレメント取得
  • (window.)document.getElementsByClassName
  • class名でDOMエレメント取得
  • console.dir
  • 対象を階層化してコンソールに出力
  • console.log
  • コンソールに一般タイプのログを出力
  • console.time
  • 時間計測用出力(開始)
  • console.timeEnd
  • 時間計測用出力(終了)
https://developer.mozilla.org/ja/docs/Web/API/Windowhttps://developer.mozilla.org/ja/docs/Web/API/console




続いて、イディオム的なところを見ていきます。


 ループ


オブジェクトの中身とか見たい時とかよく使います。僕は。
JavaScriptのオブジェクトは連想配列みたいに
キーバリュー構造になっているというのが重要ですね。
何入ってのかな~ってよくループして眺めます。



for(var key in obj ) {
console.log("key=" + key + ": value=" + key[obj]);
}


2015/06/07追記


・ブラウザのデベロッパーコンソールとか使えばオブジェクトの中身は見えるがな
・console.dirというものがあってだな…
・hasOwnPropertyは使おう

というコメントをもらいました。仰るとおりですね(^^;

ということで、全然for - inのループを使う例としては良くないものでした。。。

console.dirはオブジェクトの中身を階層構造で一気に見れるので
keyとvalueもざっと見れるもののようです。

hasOwnPropertyを使わないとプロトタイプの親のプロパティも全てループしてしまう
ので、セオリーに反すると。なるほど。



サンプルコードもコメントでいただいてます。

var objA = { a: 1, b: 2 };
var objB = Object.create(objA);
objB.c = 3;

for(x in objB){
console.log(x);
} // c, a, b

for(x in objB){
if(objB.hasOwnProperty(x)){
console.log(x);
}
} // c

// Object #keys#forEachを使う
var m = {a: 1, b: 2};
Object.keys(m).forEach(k => console.log(k + ", " + m[k]));




 Function


JavaScriptの関数の実体はFunctionというオブジェクトです。
ただ、それを表現する方法、呼び方がいっぱいあるだけです。多分。

2015/06/07追記


関数の書き方に関しては主に巻き上げが起こるか、起こらないかが
重要なポイントのようです。
http://bonsaiden.github.io/JavaScript-Garden/ja/#function.general


関数文


よくある関数ですね。

function addFuncSentence(a, b) { return a + b };



関数式


変数に代入される関数を関数式と言うっぽいです。

var addFunc = function (a, b) { return a + b };
addFunc(1, 1) // => 2


無名関数


名前を持たないfunctionのことです。Javaでいう無名クラスに近いかなぁ。



(function(a, b) { return a + b; })(1 , 1); // => 2


メソッド


メソッドとは言いますが、オブジェクトのプロパティとして
関数を持つ場合にメソッドと呼びます。

var calculator = {
add : function(a, b) { return a + b; }
}

calculator.add(1, 1) // => 2


クラスという概念は無い。全てオブジェクトです。 (ECMAScript 6ではクラス構文を作る流れもありますが、これまでの歴史としてはありません)

こういう書き方もできます。
var calculator = new Object();
calculator.add = function(a, b) { return a + b; };
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Functions_and_function_scope

 演算子



注意すべきなのは
==と===
基本的に===を使う方が思った挙動をしてくれる。
後は必要に応じてかなぁ。


https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators

 その他プロトタイプチェーンとか



このスライドが素晴らしいです。


http://www.slideshare.net/yuka2py/javascript-23768378


 Javaのアレ、JavaScriptだとどうやるの



  • クラス継承

  • JavaScriptにはない。プロトタイプチェーンでの継承が使える。

// 関数オブジェクトの生成
var Greeter = function(){};
// プロトタイプ属性の利用
Greeter.prototype.greet = function(){ console.log("hello")};
var greeter = new Greeter();
greeter.greet(); // => hello
// 関数オブジェクトの生成
var AnotherGreeter = function(){};
// プロトタイプ属性の注入
AnotherGreeter.prototype = new Greeter();
var another = new AnotherGreeter();
another.greet(); // => hello

うーん。書いててやっぱりプロトタイプの仕組みはよくわかってないです。
もっと勉強せねば。


  • オーバーライド
  • JavaScriptにはない。プロトタイプチェーンなどが使える。
// (上のつづき)
another.greet(); // => hello
another.greet = function() {console.log("another"); };
// インスタンスに対しての関数が優先される
another.greet(); // => another


2015/06/07追記


これだとこのanotherってオブジェクトに対して関数の上書きを行うだけなので、
オーバーライドというのには微妙で、あんまりやる手法でもないそうです(^^;


  • オーバーロード
  • JavaScriptにはない。argumentsとかで頑張るぐらいです。 だったら、元から関数名変えたり設計変えたりした方が良いなぁって なると思います。


    2015/06/07追記

    コメント引用しておきます。。

オーバーロードはふたつパターンがあると思います。引数の数違いと変数の型違い。
前者は arguments で凌ぐか call とか apply 呼び出しをする関数をクッションしてやるとかします。
後者の場合はダックタイピング的な感じでやっちゃえばいいですね :)




  • Enum
  • JavaScriptにはない。ただ、配列で疑似的なものは作れます。


    var DIRECTION = {
    NORTH : 1,
    SOUTH : 2,
    WEST : 3,
    EAST : 4
    };
    • アクセス修飾子
    • JavaScriptにはない。get/setキーワードとクロージャで頑張るぐらい。
    • Getter/Setter
    • getキーワードとsetキーワードがあります
    https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/get
    https://developer.mozilla.org/ja/docs/JavaScript/Reference/Operators/set

    ※サポートされていない場合 (特にIE6-8において) 、スクリプトはシンタックスエラーを引き起こします。


    • リフレクション
    • 関数オブジェクトの受け渡しが出来るのであまり使うことは無いと思います。
      ただ、やるとすれば、evalとargumentsなどを使うとそれらしいことは出来ます。
      ※ECMAScript 6ではReflectやProxy Handlerというものが実験段階ですが考案されています。

    https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Reflecthttps://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Proxy/handler

    • lamdaとか

    • 現状無いです。ECMAScript 6でアロー関数っていうのが提供されるかもしれないみたいですね。

    • mapとかfilterとか

    • ECMAScript 5からはあります。ECMAScript 6からはアロー関数が入ってさらに書きやすそうですね。

    // ES 5
    [1, 2, 3].map(function (i) { return i * i });
    // ES 6
    [for (i of [1, 2, 3]) i * i];
    // ES 5
    [1,4,2,3,-8].filter(function(i) { return i < 3 });
    // ES 6
    [for (i of [1,4,2,3,-8]) if (i < 3) i];
    (https://www.xenophy.com/javascript/8447より引用)


      2015/06/07追記


      >map/filter に関しては現状 underscore or lo-dash を使うのがモダンでないブラウザにも対応していてベター感あります。


      おおぉ、こんなものが。ECMAScript5な現状ではこれが良さそうですね。いい情報もらった。

      lodash
      prototype JavaScript Framework



    • Javadocのようなもの

    • JSDoc,YUIdoc,docco,doxx,とかいうものがあるらしいです。
      Javaエンジニアなら断然JSDocが環境構築、記法的に楽な気がします。

      http://qiita.com/opengl-8080/items/a36679f7926f4cac0a81




     まとめ



    Javaの人からみたJavaScriptというテーマで今回は考えてみました。
    見てみると色々便利そうですよね。

    プロトタイプチェーンとクロージャ、
    関数渡しなどを使えば柔軟なプログラミングが出来る
    シンプルな言語です。

    ほとんどJavaScriptの基礎的な部分の紹介に費やしてしまった。
    Javaエンジニア向けとして書けたのは「Javaのアレどうやるの?」
    の部分ぐらいですかね。
    もっとジャヴァジャヴァさせたかったのになぁ。。


    それと型システムや静的・動的型付けなどについても
    調査及び言及できればと思ってたのですが、
    それはまた今度ってことで(^^;
    あと、jsライブラリの話もしたかったなぁ。。



    結論としては、
    ・グローバルオブジェクト
    ・グローバル関数
    ・オブジェクトの種類
    ・funtionの使い方
    を覚えればそんなに難しいものではない!!

    (もちろん、言語の世界は広く、どれもこれも極めるのはムズいですけどね。)

    第3回かわいいKotlin勉強会で運営+発表してきました

    $
    0
    0






     はじめに




    2015年06月05日に行われた第3回かわいいKotlin勉強会で運営&発表してきました。
    会場はドリコムさん!(いつもありがとうございます)


    その時に話せなかったこぼれ話や補足をしようかなと思います。





      自分の発表について補足




    Server Side Kotlinについて、というお題目で発表しました。





    当日、言えなかったこととしては

    ・Karaは将来性あると思うんだけど、今のところ止まりぎみ
    ・mavenセントラルにまだアップされてないので、リポジトリをgit cloneする必要あり
    ・M11までは対応してるけどM12はまだ
    近々確認しておきます。
    ・wasabiに関してはmavenセントラルにアップされてるのでmavenやgradleといったビルドツールから割とすんなり利用可能
    ・M11は対応。M12はまだ確認とれてません
    ・Spring Bootについて紹介させていただきましたが、お進めていたのは以下の本です



    はじめてのSpring Boot―「Spring Framework」で簡単Javaアプリ開発 (I・O BOOKS)
    はじめてのSpring Boot―「Spring Framework」で簡単Javaアプリ開発 (I・O BOOKS)



    これ読んどけば間違いないと思います。
    Spring BootもKotlinもバージョンアップが進んでおり、過去のバージョンより書きやすくなってます。
    それに関してはまた別エントリ書きたいな。書きます多分。



    あとは、時間が許すならKaraのデモやりたかったし
    wasabiで僕が実装したソースの説明とかもしたかったけど。
    時間オーバーしそうな予感はしてたので割愛しました。


    現状使いやすいのはwasabiとSpring Boot。Karaは今後に期待しましょう、という感じです。

    ただ、最近のJetBrainsの動きを見ていると
    Kotlinの言語仕様を固めにかかっている点、
    Androidディベロッパー向けのライブラリ展開や言語調整をしているように個人的には感じます。
    Webフレームワークのプライオリティは低めかなぁと。
    もうちょっと頑張ってくれても良いのにな。とか。

    ということでissueとプルリクとかこっちからプッシュしていきたいですね。




     その他の発表者の資料と所感




    たろうさん

    Kotlinらしさを一番知ってる方だと思うのでこの発表聞きたかったなぁ(受付してた)。
    関数型のアプローチというと語弊があるかもしれませんが、そういうものを織り混ぜつつ、
    言語仕様として強力な部分を積極的に使うたろうさんらしさが出てて良いなぁと思いました。
    ただまぁ、言語は同じでもユースケースはいくつもあると思います。
    セオリーをおさえアンチパターンは避けつつ、自分なりに最適化してKotlinを使っていきたいですね。


    きりみんさん

    これもゆっくり聞けなかったです。
    今回の参加者層はAndroidな人が多かったので
    内容的には一番マッチしてたんじゃないでしょうか。実際の利用経験談ということで説得力あったと思います。
    僕もAndroidアプリKotlinでつくるぞー。



    みけさん

    みけさんは体調悪い中来てもらってありがとうございますという感じです。
    nativeアノテーションでJQuery簡単に呼び出す方法はあるんですが、
    型安全性をしっかり求めるならみけさんがやってたようなアプローチが必要です。多分。
    あとJQueryしか今のところサポートしてないとか、ちょっと薄目ですね。
    別に自前でやっちゃえばなんでもKotlinのクラスとして
    jsのライブラリは使えるわけですけど、
    そのあたりのエコシステムの改善は欲しいかなというところです。



    あやぴーさん

    Clojureでした。詳しくはあやぴーさんのblog読んでいただければ良いと思います。
    Kotlinじゃないやないか、みたいに思った方もいるかもしれませんが、
    アプローチが違うだけであれもひとつの形かなと思います。


    むろほしさん

    C#の人におすすめするKotlinという感じでした。
    なんでしょう、参加者の空気感を把握するのに長けてますねむろほしさんは笑
    客観的にKotlinを見てるし、良いところも把握されているなーと思いました。
    そしてめっちゃ爽やか!


     今回の勉強会について



    運営やりつつ発表するのは地味に忙しいなと思いました。
    脳みそでタスクをパラレルで動かせないのでテンパっておりました。
    あやぴーさんのblogでも指摘されてますけど、タイムテーブルにバッファ持たせれば良かったなぁ、
    とは思いつつ。発表間のインターバルは確かにあった方が良かったと僕は思います。
    結構詰め込んだので仕方ないかなぁとも思いつつ。

    ※補足ですが、全体スケジュールとしては
    休憩時間とクロージング時間で予定が狂ったときの時間調整はする予定でした。


    たろうさんとは事前にお互いの発表内容のアバウトな話はしてて、
    前提知識として

    ・Kotlinの基本的な文法は抑えてる
    ・過去の発表で行った内容と重複しない発表をする

    って感じで内容考えたので、多少Kotlin調べずに来た人には辛かったですかね。
    どうだったでしょうか。

    僕については昔ぱとさんが発表した内容と被ってるところ結構ありますけどね笑

     懇親会



    18人ぐらい参加していただいて大盛況でした!

    なんかぐだっと乾杯してすみませんでした笑


    クラスメソッドの@com4dcさんはなんと、
    北海道から足を運んでいただき、ロイスのチョコを持ってきてもらったので、
    ビールとオードブルとお菓子と一緒に食べました。
    (ロイスのチョコでテンション上がるの僕だけかな)


    もっといろんな人と話したかったのですが、時間足りずタイミングつかめずで残念!またどこかで皆さんお話しさせてくださいー!


      コミュニティについて個人的に



    コミュニティとしてJKUG(Japan Kotlin User Group)を成熟させたいという思いがあります。
    今のところ1年に1~2回程度の頻度でKotlinの勉強会は行われていますが、
    もっと発信しあって、お互いの情報共有なり技術向上の場としたいですねー。
    方法とか方針はまだ何も考えてないですけど、コミュニティの基盤を固めていきたいですねー。



     まとめ



    ということで、今回のブログをまとめると

    ・自分の発表で説明足りなかったかなってところを改めて
    ・他の方の発表の感想
    ・コミュニティ盛り上げたい助け合いたい
    ・懇親会いっぱい来てくれてありがとうございます


    って感じです!!

    今回はAndroidな人が多かったんですが、
    Android以外でも使えるので言語好きな人、ライブラリをKotlinで作ってみたい人
    サーバーサイドKotlinでやりたい人、altJSとしてKotlinやりたい人、
    とかいろんな人が集まってきたら面白いなーと思います!


    僕らのKotlinはまだ始まったばかりだ!




    Javaエンジニア養成読本をようやく読んだので感想

    $
    0
    0




     はじめに



    2014年の秋ぐらいにたしかJavaエンジニア養成読本という本が出てまして。
    僕、すぐポチッと買ったんですよ。共同著者の皆さんに(8割ぐらい)サインまで貰ったんですけど、
    ゆっくりゆっくり読んでたら全部読見終えたのが今日という…(激遅)


    結論を言うと、以下の人は読みましょう。


    ・僕と同じぐらいのキャリアの人(2〜3年前後とか)
    ・Javaの研修は終わったぜー、これからプロジェクトで頑張るぜって人
    ・ワタシJavaチョットデキル人


    Java覚えたての人、Javaを使って仕事しているけどなんだか自分の中に答えを持てない人。
    ハッタリで仕事してる人。とか、とにかく一回読んで損はない内容だと思いました。

    あと、Androidな人もよんでほしいなー。なんとなくですが。

    うっすい本なのですぐ読めますよ!!!


    ということで、感想を書いていこうと思います。




     誰も教えてくれないJavaの世界


    きしだ なおきさんパート。

    Javaを使う人が知るべき歴史、文化、用語を解説しています。
    仕事でいろんな人と話をしているとJavaっていたらJavaでしかなくて、
    Java SEもJava MEもJava EE、明確に知らなかったりします。
    IDEの解説にしても何にしても重要なだと感じました。

    Javaの世界がもっと身近になる章です。


    あなたと!Java!アレ!



     Java入門


    のざき ひろふみさんパート。

    Effective Javaぐらいには僕にはエフェクティブな内容でした。

    特に目新しい話があるわけではないですが、すごい出来る人は当たり前に知ってる内容
    を分かりやすく書いてくださっています。

    僕にとっては当たり前ではない内容ばかりだったのでとても勉強になりました。

    Javaの入門、裏面みたいな感じですかね。


    なんでしょう、知識はバームクーヘンのように薄く積み重なって成り立っていくと
    誰かが言ってましたが、
    Java入門2周目みたいな感じです。


    同じハローワールドや例外、クラスについてでも入門書が教えているそれとは
    違います。

    だから知ったかぶったオッサンにココらへんのことを突っ込んでみると
    答えられなかったりすると思います。

    また、絶賛Java入門1周目だった僕にとっては
    見落としていた、理解を深められずにいた部分が明確になりました。




     Java SE 8時代のデータ処理入門


    吉田真也さんパート。

    Java SE 8の目玉機能としてProject lambdaやStream APIなどの話は
    広く知られていると思いますが、そのあたりの話を体系的に詳細に
    書かれていて分かりやすかったです。

    ネット上に分散しているようなものではなく、やはりまとまった文章は
    参考になるなと思いました。

    分かりやすい図解、用語の定義、など曖昧に覚えていたことが
    だいぶスッキリしました!
    Java SE8を使うシーンで何回も読み返したいですねー。


    あ、こんなメソッドあったんやとか言うのもいっぱいあったし、
    個人的には縦の問題とか横の問題って言葉が印象に残りました。




     現場で役立つJava EE


    Challenge Java EE !でおなじみの菊田洋一さんパート。

    普段仕事でJava EEを使っているので、
    自分の復習として見ていきました。

    いつも思いますが、きくたろーさんの文章は綺麗で丁寧ですよね。
    雑の極みの僕としては頭が上がらないなぁと思います(^^;

    色んな方が言ってると思いますが、Java EEは広すぎて
    解説に苦労されたんじゃないかなあと思います。

    Servletは思い切ってカットしちゃっても良かったかもしれないです。
    ここらへんはうらがみさんの書評と大体同じ意見な気がします。


    「Javaエンジニア養成読本」読んだ


    ホントにこの章の内容やChallenge Java EEのブログには
    お世話になりまくりなので、いつもありがとうございます!!!

    ※そりゃ、普段からblog拝見してるから本の内容はおさらいになるよなーとか




     現場で役立つチーム開発入門


    JUnit実践入門で有名なクラスメソッドの渡辺修司さん。

    わたなべさんもさすがというか。文章めっちゃ分かりやすくて。


    なぜ現場で
    「なぜバージョン管理をするのか」
    「なぜビルドツールを使うのか」
    「なぜJenkinsを使うのか」

    などなど、スッキリ分かります。

    特にチームでのgitの使い方とか参考になりました。

    git、maven、jenkinsなどを現場で導入する場合に説得力のある背景知識を身に着けるなら、
    必読じゃないかなーと思いました。


     イマドキのJava受託開発の現場で求められる知識


    いがぴょんさんこと、伊賀敏樹さん。

    有名ないがぴょんさん。以前にJJUGのナイトセミナーでお会いした時も
    おもしろ人だなぁとともに、リアリストな感じがしました。


    本章もJavaの現場がリアルに書かれてるのかなぁという気がします。
    Javaを使っている現場が求めているもの、フェーズなど。

    他の章とは微妙に対象としている読者が違うような印象も受けました。
    受託の現場に出始めの新人とか向けなのかなぁとか。


    やっぱ、各現場の標準とかルールとかシステムベンダーごとの
    やり方の違いが難しいところだなあと思います。

    そういうノウハウの蓄積はもちろん企業として重要で
    それに適応する能力も大事で。

    とかいう思いは以前に僕が現場ロックインがうんたら、、とか言って書きましたので割愛。




     まとめ



    それぞれ感想書かせていただきました。

    いい本なので、感謝の意味も込めて各パートの色々感じたことを
    書いたつもりです。


    一読して損はないので、
    買ってない人は買いましょう!!

    そういえば増刷も決まったらしいですし。


    Javaエンジニア養成読本[現場で役立つ最新知識、満載!]
    Javaエンジニア養成読本[現場で役立つ最新知識、満載!]



    JavaのREPL、project kullaがスッゴイ便利!

    $
    0
    0






    ※注意

    本記事は2015/06/12現在のproject kullaに関する情報です。
    今後のJava SE 9のリリースやproject kullaの開発状況によっては内容が変わる可能性もありますのでご了承ください。


     はじめに



    Java SE 9ではJavaにREPLが入る予定となっています。

    その名もproject kulla!!


    とある記事を読み、リリース前ですが今でも使えることを知りました。
    これは使ってみたい!ということでトライしてみました。




     そもそもREPLとは



    REPLとは

    Read-eval-print loopの略

    字のごとく読んで評価して表示して繰り返す。対話型評価環境を指す。ただし、インタープリタと同義ではない。

    多くの関数型言語やスクリプト言語では利用出来る。

    http://d.hatena.ne.jp/keyword/REPLより引用)



    REPLについては以前にもWeb上にあるREPLをまとめた記事を書きました。

    JavaのWeb REPLもあるにはあるのですがちょっと反応が遅いのが個人的にはネックでした。


     どこが便利か


    対話環境なので、一つ一つのプログラムの評価が早く、
    書いたタイミングですぐに挙動の確認が出来ます。

    また、ビルド、デプロイやテスト実行などの必要もなく
    インプットに対してのアウトプットをすぐに知ることが出来ます。
    これは素早い開発を行いたいときにかなり便利だと感じています。

    kullaに関してはコンパイルもあまり意識させず、
    スクリプト言語のような体感でJavaのプログラミングが出来ると言えます。



     便利な利用シーン



    ・写経

    プログラミングにおける写経です。
    説明を読みながらサンプルプログラムを真似て書いてみる。
    僕は書いた方が断然理解が早まるのでありがたいです!


    例えば最近だと、櫻庭さんのJava技術最前線
    Date and Time APIの記事を読みながら写経していました。

    画面半分をブラウザで記事表示、もう半分をREPLって感じでなるべくウィンドウの行き来を意識しない感じでやるようにしてます。



    イメージ)






















    ・IDEでの開発

    IDEのプラグインだったりしますが、
    軒並みJavaの提供するIDE(Eclipse、NetBeans、IntelliJ IDEA)では
    コマンドプロンプト/ターミナルが使えます。
    利点については前述したものと同様ですが、コンパイルチェックで
    確認できないようなものをさっと確認するのに役立つはずです!
    (ただクラスパス通したりがちょっと面倒かな…?)


    ・設計段階でのAPIの動作確認

    IDE立ち上げるのもめんどいわ!ってときもあると思います。そういうときもREPLなら即起動、即確認ができます。



    ・テストを書くほどでもない確認

    テスト書かないとか…ってサバンナ方面から言われそうですが、細かな動作確認ぐらいのものならREPLで充分ってことはありえると思います。




     project kullaの使い方



    ・環境構築

    さて、本題のkullaの使い方です。
    これに関してはすでにいくつか記事にある通りで、
    JDK9とkullaの実行可能jarを用意するだけです。

    JDK™ 9 Early Access Releases
    project kullaのナイトリービルド



    JDK9のJAVA_HOMEにパスを通した状態で



    java -jar kullaxxxxxxx.jar

    とjavaコマンドを実行するだけで対話モードに入ります。簡単ですね!



    動作確認はWin 7 32bit、Mac OSXで行いました。
    Winの方が今のところ安定しないかも。。。充分使えるんですが。
    Mac OSXの方が快適です笑


    ・使い方

    REPLモードに入ればもうすぐにJavaのプログラミングが出来ます。

    例えば

    import java.util.stream.*;
    IntStream.range(1, 10).forEach(System.out::println)

    なんてのもすぐ書けちゃいます!!


    Shiftキーを押すとコードアシストまでしてくれて賢い!しかもスピーディーです。


    ちなみにREPLはデフォルトの状態で
    java.lang以外のパッケージに関しても7つのパッケージをimportしています。


    import java.util.*;
    import java.io.*;
    import java.math.*;
    import java.net.*;
    import java.util.concurrent.*;
    import java.util.prefs.*;
    import java.util.regex.*;
    などがimportされているので、なにも考えずにコレクションの操作なども可能です。

    /hまたは/helpを押すと各コマンドのヘルプを出力してくれます。
    これ見れば大体は分かると思います。
    -> /help
    Type a Java language expression, statement, or declaration.
    Or type one of the following commands:

    /l or /list [all] -- list the source you have typed
    /seteditor <executable> -- set the external editor command to use
    /e or /edit <name or id> -- edit a source entry referenced by name or id
    /d or /drop <name or id> -- delete a source entry referenced by name or id
    /s or /save [all|history] <file> -- save the source you have typed
    /o or /open <file> -- open a file as source input
    /v or /vars -- list the declared variables and their values
    /m or /methods -- list the declared methods and their signatures
    /c or /classes -- list the declared classes
    /x or /exit -- exit the REPL
    /r or /reset -- reset everything in the REPL
    /f or /feedback <level> -- feedback information: off, concise, normal, verbose, default, or ?
    /p or /prompt -- toggle display of a prompt
    /cp or /classpath <path> -- add a path to the classpath
    /h or /history -- history of what you have typed
    /setstart <file> -- read file and setas the new start-up definitions
    /savestart <file> -- save the default start-up definitions to the file
    /? or /help -- this help message
    /! -- re-run last snippet
    /n -- re-run n-th snippet
    /-n -- re-run n-th previous snippet

    Supported shortcuts include:
    <tab> -- show possible completions for the current text
    Shift-<tab> -- for current method or constructor invocation, show a synopsis of the method/constructor

    /lを押すと今まで宣言した変数の確認が出来ます。
    /rで今まで入力した内容をリセットします。


    こぼれ話ですがこんなことも出来ます…楽しいですよ!




    ということで、/debugと打ち込めば、kullaのデバッグログが表示されるようになります!!



    -> /debug
    | Debugging on

    -> import java.util.stream.*
    Compiling: import java.util.stream.*;
    Kind: IMPORT -- import java.util.stream.*;

    Successful compile ===
    import java.util.stream.*;
    Status: Active, Kind: ImportKind
    Requesting redeclare printf
    Compiler generating class REPL.$REPL8
    Successful compile ===
    package REPL;
    import java.util.*;import java.io.*;import java.math.*;import java.net.*;import java.util.concurrent.*;import java.util.prefs.*;import java.util.regex.*;import java.util.stream.*;publicclass $REPL8 {
    publicstatic
    void printf(String format, Object... args) { System.out.printf(format, args); }}

    Status: Active, Kind: MethodKind
    Redefinition of printf.



    あと、宣言した変数は全て実行毎に別々のクラスのフィールドとしてstaticに宣言されているようです。


    このあたりはOpen JDKのコミッターであるきつねさんに教えてもらいました!
    皆さんも使う際にはフィードバックするとより良いツールになってくれると思います。



     まとめ



    今回はJava SE 9で導入される予定のproject kullaが楽しかったので紹介として記事を書いてみました。

    僕は主に写経用に使う予定ですが、
    すぐに調査したい(例えばいきなり質問されてすぐ確認したい)時とか
    役に立つこと間違いなしだと思ってます!

    REPL文化のあるClojureだとかはハッカソンでREPLを使いながら
    動くアプリケーションを作ったなんて事例も聞いたことがあります。


    Javaでも受け入れられてコーディングのスタイルが広がれば、
    もっと楽しくなりますね!


    開発もスムーズになるはず!




    Kotlinでテスト用の雑なDSLを作った

    $
    0
    0




     はじめに



    Javaでまぁ、JUnitでテスト書きますよね。



    テスト書くときにassertまでの間にインスタンス生成やら、
    初期化やらset/getやらゴチャゴチャ書いてしまって見にくいな…って思ったことありませんか?

    ということで、そこらへんを考えながらKotlinでテスト用のDSLを作ってみました。



     setup、exercise、verify



    JUnitでテストするにあたって、僕としてはJUnit実践入門の教えを守りたくなります。

    JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)


    基本的にテストは
    ・setup(準備)
    ・exercise(実行)
    ・verify(検証)
    とかに分かれますという話です。


    こんな感じ。





    publicclass SumTest {

    @Test
    publicvoid testSum() {
    // setup
    Hoge hoge = new Hoge();
    hoge.setHogeHoge("hogehoge");
    hoge.setHogeFuga("hogefuga");
    hoge.setHogePiyo("hogepiyo");
    Fuga fuga = new Fuga();
    fuga.setHogeHoge("hogehoge");
    fuga.setHogeFuga("hogefuga");
    fuga.setHogePiyo("hogepiyo");
    Piyo piyo = new Piyo();
    String expected = "piyo";
    // exercise
    String actual = piyo.sum(hoge, fuga);
    // verify
    assertThat(expected, is(actual));
    }
    }



    こう書くと、コメントで区切られてるだけでなんの規約も無いなぁと思うわけです。
    テストをうまいことsetupとexerciseとverifyで三分割したい。


    だからcucumber-jvmとかspockとかそういうものがあるんでしょうけど
    (というとそれもまた語弊ありそうなんですけど)。

    なんか簡単にそういうもの作れないかなぁと。


    ※ もちろん@Beforeやら@Afterやら@Ruleとかそこらへん使ってシンプルにすることもセオリーですが。



     KotlinでDSLを考える



    ということで、なんか頭の中にあるイメージを具現化したいなぁ
    と思って思い付いたのがKotlinだったので、Kotlinで書きました。
    別にJavaでも良かったんですが。



    import org.junit.Test
    import kotlin.test.*
    import java.util.*
    import kotlin.properties.Delegates


    ///////////////////////////////////////////////////////////////////////////
    // テスト対象
    ///////////////////////////////////////////////////////////////////////////

    fun sum(a : IntArray) = a.sum()

    ///////////////////////////////////////////////////////////////////////////
    // DSL
    ///////////////////////////////////////////////////////////////////////////


    class DslFactory {
    companion object {
    fun create() = DslSetup()
    }
    }

    class DslSetup{
    var expected : Any by Delegates.notNull()
    var args : Array<Any> by Delegates.notNull()

    fun setup(f : (self : DslSetup) -> Unit) : DslExercise {
    f(this)
    return DslExercise(expected, args)
    }
    }

    class DslExercise(expected : Any, args : Array<Any>) {
    var actual : Any by Delegates.notNull()
    val expected = expected
    val args = args.asSequence()
    fun exercise(f : (self : DslExercise,args : Sequence<Any>) -> Unit) : DslVerify {
    f(this, args)
    return DslVerify(actual, expected)
    }
    }

    class DslVerify(expected : Any, actual : Any) {
    val expected = expected
    val actual = actual
    fun verify(f : (expected : Any, actual : Any) -> Unit) = f(expected, actual)
    }

    // ただのまやかしにすぎない拡張関数
    fun Sequence<Any>.second() = this.drop(1).first()
    fun Sequence<Any>.third() = this.drop(2).first()
    fun Sequence<Any>.at(i : Int) = this.drop(i - 1).first()

    ///////////////////////////////////////////////////////////////////////////
    // テスト
    ///////////////////////////////////////////////////////////////////////////


    publicclass Tests {

    val test = DslFactory.create()
    @Test
    fun testSum() {
    test.setup { target ->
    target.expected = 6
    target.args = arrayOf(intArrayOf(1,2,3))
    }.exercise { target, args ->
    val arg1 = args.first() as IntArray
    target.actual = sum(arg1)
    }.verify { expected, actual ->
    assertEquals(expected, actual)
    }
    }

    }



    ポイントとしては
    ・setup、exercise、verifyの責務を明確にする
    ・メソッドチェインで順序性を保(とうとし)てる
    ・expectedやargsを初期化していないと実行時例外が発生する(setupでの宣言を矯正する)


    んで、クソダサいのがテスト対象の引数をsetupで作るんですが、
    exerciseブロックではもう一度受けとり直してキャストしてるってところですね。
    非常に型安全な感じもなく、手続きっぽい手口です。


    ここらへんの受け渡しのダサさを回避する方法考えると
    setup、exercise、verifyの順番にネストしてclosureを利用する方法があると思うんですが、
    なんか可読性下がるなぁと。そこらへんspockはよく出来てる気がする。
    というかアレの仕組み誰か教えてください笑



     まとめ



    ホントに作ってみただけですが、
    一応目的であったテストブロックの分割と責務の分散というか
    そういうものが出来ました。

    実用性があるかといえば…ですが、
    Kotlinの言語の特性とかユニットテストの考え方とかの話のタネにでもなればな、と。



    どうしてもspockすげえなぁという感想になる。
    あとKotlinにはspekというものがあるので、
    JetBrains/spek - GitHub本格的なテスティングフレームワークみたいなぁという方はそちらを。




    JJUG ナイトセミナー 「Reactive Streams特集」に行ってきました #jjug

    $
    0
    0



    http://www.zhaojunlucky.com/architecture/what-is-reactive-systems/より引用

     はじめに


    JJUG ナイトセミナー 「Reactive Streams特集」に参加してきました。

    本記事では実際に参加して感じたこと、学んだことをメモがてらまとめようと思います。



    今回参加の目的としては
    ・自分の中でバズワード化している「リアクティブ」な用語が分からない
    ・概念はどんなものか?
    ・ただのObserverパターンじゃないの?
    ・ただのFuture/Promiseじゃないの?
    ・ただのデータバインディングじゃないの?
    ・Stream APIっぽい関数型パラダイム的な何かじゃないの?

    というところの曖昧さの整理とか勉強のためでした。


    すでに色んな方がレポートを書いてます。みんな仕事が早いですね(^^;


    JJUGのReactive Streams勉強会に行ってきました! - Java EE 事始め!
    JJUG ナイトセミナー「Reactive Streams特集」に行ってきた #JJUG - mike-neckのブログ
    JJUG ナイトセミナー 「Reactive Streams特集」に行ってきた #jjug - yukungのブログ






     岡本雄太 (@okapies) さんの発表





    90枚近くスライドがあり、時間に対して量が多かったみたいで若干早めのペースで
    発表をされていました。
    でも予習してきた人とか、このあたりの知識がある程度ある人には丁度良いぐらいの
    ペースだったようにも思います。


    非常に分かりやすい発表でした。


    Reactive Streams周辺の話から入り、Reactive Streamsの説明をした感じ。
    概要や全体図をつかむには申し分ない内容でしたね。

    ・プログラミングモデルとしてのReactive Programming
    ・ランタイムとしてのReactive Streams
    ・アーキテクチャとしてのReactive Manifesto。


    Reactive Manifestoは大雑把に言って、Reactive Systemsという
    非同期なデータフロー処理のアーキテクチャを定めようというものだと捉えました。


    ただ、Reactive Programmingに関しては
    Reactive Manifestoから派生した言葉ではないんですね。
    Reactive Programmingはプログラミングのモデルであって、
    Reactive Manifesto起因ではない。Reactive Manifestoも
    Reactive Programmingという言葉は意識的に避けるようにしているとのことで。



    Reactive Streamsの特徴として強く印象に残ったというか釈然としたのは
    「バックプレッシャー」という概念の説明を聴いた時でした。

    そこは確かに従来のデータフローの仕組みにはなかったところなのかなと。


    JSRとしてJava SE 9へ取り込もうという動きも知らなかったですね。
    そしていろんな実装がある。
    RxJavaとAkka StreamsとかVert.xぐらいしか名前知らなかった。。。

    RxJavaは軽く暇つぶしに書いたことあるので、
    RxJavaの処理フローをイメージしながらお話を聴いておりました。


    しかし、Reactive Streamsの規定する部分というのは
    スライドにもあったとおり、ビッグデータだとか、動画サイトだとか
    そういう大量の通信をさばくシステムに携わってないとピンと来ないのでしょうね。
    それに加えて、非同期処理でのコールバックヘルとか
    体験しないとありがたみがわからないかもしれません。


    実際そういったシステムのためのアーキテクチャなので、
    そこを想像出来ないと興味もわきにくいでしょうし、
    実際に使うとなると、具体的に利用シーンが思いつかなかったりするかもなぁ。



    Reactive Streams自体はSPIとかインターフェースでしか無いです。多分。

    https://github.com/reactive-streams/reactive-streams-jvm/



     よしだ (@grimrose) さんの発表



    Reactive Streamsを使ってみよう
    発表資料関連


    とーます(@grimrose)さんの発表でした。

    具体的に実装の話についてでした。
    Reactive Streamsが提供するインターフェースは
    ・Publisher
    ・Subscriber
    ・Subscription
    の3つがメインだそうです。



    ProcessorはPublisherとSubscriberの共通機能ということで、
    あまり意識しなくて良いと。


    PublisherからObservableへのコンバート、
    ObservableからPublisherへのコンバート
    もあるようで、実装はそれぞれ全然違うけど
    Reactive Streamsが頑張って対象のインターフェース型に変換してるとのことでした。

    「なるほどReactive Streamsというのはインターフェースの規定とコンバートがメインかな。
    なんだか通信プロトコルとやってること近いな。」
    と思ってたら、reactive streamsの原文にそんな感じの記載がありました。



    This encompasses efforts aimed at runtime environments (JVM and JavaScript) as well as network protocols.




    調査量がすごくて、どこが参考になるかという点でも大変有益な発表だったと思います。
    あと、Akka StreamのテストキットがJavaだとつらそうだなぁとすごい思いましたw



     懇親会



    本編もそうですが、懇親会も含めて今回のナイトセミナーはなんだか
    とても雰囲気が良かった!勉強になりましたし
    なんだかピースフルな空気でした。


    とーますさん(@grimrose)とも改めてお話しました。
    Reative StreamsのPublisherからObservableへの変換とかは結構エグいとのことでした。
    実装によって中の処理が全然違うんだとか。QueueとかRing Bufferとか。
    そこの変換を保証するのがインターフェースの型とTCK(JSR用のテストキット)
    っぽい感じのようです。
    あとユニットテストがつらそうですね、って話もしました。
    ノンブロッキングで動いているので、全部ブロックしてassertionしないといけないとか。
    中間操作をどうやって検証するかとか。テスト用のStreamとやらもあるそうですが。


    しかし、とーますさん(@grimrose)の幅の広さはすごい。


    @okapiesさんとも終了間際にちょっとだけ話させていただきました。
    もうちょっと笑いがあっても良かったなぁと仰ってましたが、
    分かりやすくてめちゃくちゃ勉強になったので
    問題無いです!笑


    あと、今回は@maaya8585さんとか
    @itohiro73さんに初めてちゃんと会ってお話しました。そういえば。
    @chiroitoさんもそうかも笑
    いい人ばかりですね。




     まとめ



    ということで、JJUG ナイトセミナー 「Reactive Streams特集」に参加してきたレポートでした。

    振り返ってみて、僕の疑問

    ・自分の中でバズワード化している「リアクティブ」な用語が分からない
    ・概念はどんなものか?
    →Reactive Programming、Reactive Streams、Reactive Manifestoを理解すればまぁなんとかなりそう

    ・ただのObserverパターンじゃないの?
    ・ただのFuture/Promiseじゃないの?
    ・ただのデータバインディングじゃないの?
    →多分全部を含んで非同期でやってる。
    それに加えてバックプレッシャーでオーバーフローを防ぐ仕組みがかなりデカイ。
    あと、サービス間の互換性の高さも利点のよう。

    ・Stream APIっぽい関数型パラダイム的な何かじゃないの?
    →実装による。RxJavaとかだと似てるようにみえるかも。
    Reactive Streamsが規定しているわけでもない。と思う。


    ということでだいぶスッキリしました。
    それにこの周辺の情報の飲み込みがちょっと早くなりました。
    やはり直接詳しい人から説明を受けるというのは学習効率高いですね。

    行ってよかったなぁーと思えるナイトセミナーでした!





    SIer to SIer

    $
    0
    0




    6月30日をもって、SIerのちっちゃい会社を辞めました。
    7月からはSIerのちっちゃい会社で働きます。


    僕が強く主張したいのは、転職タイミング的に夏のボーナスが出ないということです。
    皆様のご好意をお待ちしてます!!!切実にビールとか技術書とか!!

    ほしい物リスト









     なんでやめたの?



    特に会社に大きな不満はありませんでした。
    それに技術者のはしくれとして飯を食っていけるようになったのは
    この会社のおかげなのでそこは頭上がりません。


    ただ、この会社でやりたいことは全てやったなという
    自分の中でのしきい値を超えただけです。

    客観的に見てやり尽くしたわけではないでしょうが、
    僕個人の主観としてはもうこれ以上はやることないなと。




    1年前ぐらいの段階でその結論には至ってて、
    あとは環境面、待遇面、業務内容などで良い会社
    と巡り合えればなぁという気持ちでした。




     これから何やるの?



    これからも基本的にはSIです。今まで2次請けとかでしたが
    1次請けとかやってく予定です。


    あと、社内でプロダクト作って売ろうって話もあります。
    (こっちはそこまで期待してない)



    この会社以外にも軽く誘ってくれる会社だったりとか、
    協力的な方もいたりとかで、感謝しています。






    はい、ということで、ここから下は余談とかです。




     一人で出来ることと会社で出来ること



    今まで、会社にいてやろうとしていたことって
    1人でも出来てしまうなってことが色々増えてきました。

    1人で出来る事をプライベートワークとするか仕事とするか。
    そういうことも転職にあたっては考えたりしました。


    例えば、Androidのアプリ作るとか、
    webサイト作るとか、勉強会とかで発表するとか。

    あと、学習に関してもそう。
    仕事でStruts使ってようがJava EE 7は覚えられるし、
    他の言語だって覚えられる。
    それは仕事とか環境のせいにしてはいけないし、
    個人でやれることだと思いました。


    逆に1人で出来なくて会社でやる意味のあることはなんだろうとか

    チームビルディングとか大規模開発とか
    顧客折衝とかシステムのパフォチューとか。


    そういうのも転職のポイントだったかなぁと思います。






     システムをインテグレーションしたい



    なぜSIerを続けるか、その1。


    僕は、SIという感じのなんかウォーターフォールっぽい渦の中で
    システム開発をしてきたりしてこなかったりしたわけですが、
    いまだかつで、システムをインテグレーションしてる実感がわきません。

    なんだか泥臭いことやカッコ悪いことばっかりしてる気がします。
    ってあたりは以前にも書きました。

    泥沼プロジェクト振り返り
    現場ロックインが技術力さげてるのかもしれない


    これは今まで居た会社がというよりは、
    ひとえに、僕の力不足だと思ってます。


    あと、「このプロジェクトは成功したぞー!」みたいな経験って今まであんまなかったなと。
    そういう風に自分の力で導いてこれなかった。

    だから本来の意味で、
    SIerならシステムをインテグレーションしたいわい、という思いがあります。


    そこのやり残した感があってSIerを続けたいなと思いました。
    あと、単純にいろんなシステムでの経験値が少ない。
    色んな業界の業務にも触れたいし場数を踏みたいなという。



     SIerのネガティブなイメージも消したい



    なぜSIerを続けるか、その2。


    なんかSIerはダサいことやってるとか、社畜がうんたらとかって
    話題ばかりな風潮があんまり好きではないんです。
    いや、僕もネタにすることあるんですけどね笑
    でも、もっと明るい話があってもいいのになぁとか。



    多重請負の構造とか契約形態とかっていうところまで考えは至ってなくて、
    単純にプロジェクト単位とかチーム単位で幸せな話を増やしたいなぁと思います。


    なんか、「技術がある人はSIer辞めてWebサービスの会社行くよね」
    みたいなんもすごいモヤっとするんですよね。


    そこまで僕に影響力があるわけではないですけど、
    なんでしょう、憧れられるようなチームとかが
    SIでいっぱい出来ればいいのに、と。



    キャプテン翼という漫画で葵新伍ってキャラがいるんですが、

    「ジャポネーゼ=サッカーの下手なやつを
    ジャポネーゼ=サッカーの上手いやつに変えるんだ」

    とか言ってまして、僕も気持ち的にはそんな感じに近いです。



    などと、大袈裟なことを書いてみましたが、
    いろんな場所で楽する術を身に着けたいですね、はい。
    明日にはSIが嫌になってるかもしれません!!


     経験積んだら



    30代前半を目処に、多分また結論を出します。
    ジョブホッピーでヒッピーな感じにしたいわけもないんですが、
    いろんな経験は積みたいし。


    その頃に熟練度マックスだったらバトルマスターとか賢者とかなりたいですね
    ってことです(出典:ドラクエ6)



    でもまぁ、いい話があればいつでもお声かけください。
    次の会社と自分と、、色々天秤にかけて真剣に考えると思いますので。
    (我ながら甘い考えですね)



     僕がホントに欲しかったもの



    ほしかったものはこちら!!!
    皆様のご好意をお待ちしてます!!!切実にビールとか技術書とか!!(2回目)

    ほしい物リスト






    Kotlinの雑なテスト用DSLを作りなおした

    $
    0
    0




     はじめに



    Kotlinでテスト用の雑なDSLを作るというのをやってみたんですが、
    なんかイマイチなものが出来たなぁと思います。

    記事を書いてからも改善出来ないかやり方を考えてたんですが、
    もうちょっとマシなものが出来た気がするので、今回は続編記事です(まだ洗練されてませんが)。









     前回のDSLの問題点



    前回もあげていましたが

    ・型のキャストをテスト実装者にさせる必要がある
    ・各ブロックでの情報の受け渡しが手続き的
    など問題点がありました。



     改善アプローチ



    JetBrainsの@yanex_ruさんから
    type-safe builderを利用するのとかどうですか?と教えていただいたのと、
    ジェネリクスで頑張れそうだなとか思って作ってみました。



     改善版DSL



    ソースは以下のような感じです。


    import org.junit.Test
    import kotlin.test.*
    import java.util.*
    import kotlin.properties.Delegates


    ///////////////////////////////////////////////////////////////////////////
    // テスト対象
    ///////////////////////////////////////////////////////////////////////////

    fun sum(a : IntArray) = a.sum()

    ///////////////////////////////////////////////////////////////////////////
    // DSL
    ///////////////////////////////////////////////////////////////////////////
    class Argument<T> (value : T) {
    val value = value
    }
    class TestContext<T> {
    var args : Array<Argument<*>> by Delegates.notNull()
    var expected : T by Delegates.notNull()
    var actual : T by Delegates.notNull()
    fun <T> Array<Argument<*>>.first() = this.get(0).value as T
    fun <T> Array<Argument<*>>.second() = this.drop(1).first()
    fun <T> Array<Argument<*>>.third() = this.drop(2).first()
    }
    class DslSetup<T>{
    val setupReciever = TestContext<T>()
    fun setup(recieve : TestContext<T>.() -> Unit) : DslExercise<T> {
    setupReciever.recieve()
    return DslExercise(setupReciever)
    }
    }
    class DslExercise<T>(reciever : TestContext<T>) {
    val exerciseReciever = reciever
    fun exercise(recieve : TestContext<T>.() -> Unit) : DslVerify<T> {
    exerciseReciever.recieve()
    return DslVerify(exerciseReciever)
    }
    }
    class DslVerify<T>(reciever : TestContext<T>) {
    val verifyReciever = reciever
    fun verify(recieve : TestContext<T>.() -> Unit) = verifyReciever.recieve()
    }


    ///////////////////////////////////////////////////////////////////////////
    // テスト
    ///////////////////////////////////////////////////////////////////////////


    publicclass Tests {
    @Test
    fun testSum() {
    val test = DslSetup<Int>()
    test.setup {
    expected = 6
    args = arrayOf(
    Argument<IntArray>(intArrayOf(1,2,3))
    )
    }.exercise {
    actual = sum(args.first())
    }.verify {
    assertEquals(expected, actual)
    }
    }

    }


    TestContextというクラスの拡張関数型の関数を引数に持つ関数を使うことで
    情報を柔軟に受け渡す事が出来ました。

    これはKotlinのWebフレームワークのKaraのHtmlBuilderと近いアプローチです。

    引数の関数をレシーバーとなるTestContextインスタンスで受けとることで
    情報の受け渡しを可能にしています。

    また各クラスにジェネリクスで型指定することで
    Any型(Javaで言うところのObject型)を使うことをなるべく避けました。
    ただargs.firstなどは内部でキャストしちゃってるんですけどね…。

    Kotlinのスマートキャストを使って
    うまくリターン出来ないかと考えてたんですけど、書き方がよく分からず(^-^;


    これでsetup、exercise、verifyブロックの
    それぞれで同じコンテキストを持つ事が出来ました。


    僕の思想としては、テスト対象やテスト対象のメソッド引数、
    依存するものの初期化やセットなどはsetupで、
    exerciseでは対象の実行のみ
    verifyではアサーションのみ、という方針です。



     Delegates.notNull()は微妙?



    @yanex_ruさんから
    からの指摘として、
    Delegates.notNull()を使ったフィールド変数の委譲はあんまり推奨しないと言われました。

    確かに、値の初期化がなされているか、
    コンパイルレベルでは分からなくなってしまいます。

    今回は他の良い方法が思い付かなかったので、そのままとしていますが
    たとえばexpectedに値を代入せずにアサーションを行おうとすると実行時例外が発生してしまいます。

    これはコンパイルレベルで解決できる問題かもしれません。



    また、基本的にnull非許容型を使っているので、
    actualやexpectedにnullを代入したい場合はどうすんの?とかってところもあります。
    そこはちょっと悩み中です。





     まとめ



    雑なDSLをちょっと改善してみよう、という感じで書いてみました。


    Kotlinの良さとかちょっとは出たかなぁ。。。
    テストは前回のDSLよりはやりやすくなったのでは…?!


    なんかもっとこういうのあるじゃん!
    とかいうご意見お待ちしております!笑







    JUnitのTest用Visitorのメモ

    $
    0
    0



    なんだかいつの日か、JUnitで使うテスト用のFileVisitorを作ってメモってたので、
    ブログとして残しておく。

    (イマドキはこういうのはgistとかにさっと書いてメモるもんなのかなぁ…)


    大体、JUnitでのテストでネックとなるのが

    ・どうでもいいファイルをテストの間だけ作成する
    ・画像ダウンロードとかファイル出力とかのロジックで出来たファイルの検証がややこしい
    ・どうでもいいファイルをテストが終わったら削除する


    とかだと思ってる。


    今回はどうでもいいファイルを削除することと、
    検証の方法の1つとして、生成されたファイル数をカウントするという
    雑なVisitorを作ってみた。








    ファイル数カウントVisitorクラス
    import java.io.IOException;
    import java.nio.file.FileVisitResult;
    import java.nio.file.FileVisitor;
    import java.nio.file.Path;
    import java.nio.file.attribute.BasicFileAttributes;
    import java.util.List;

    publicclass FileCountVisitor implements FileVisitor<Path> {

    private List<Path> list;

    public FileCountVisitor(List<Path> list) {
    this.list = list;
    }

    @Override
    public FileVisitResult preVisitDirectory(Path dir, BasicFileAttributes attrs) throws IOException {
    return FileVisitResult.CONTINUE;
    }

    @Override
    public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException {
    list.add(file);
    return FileVisitResult.CONTINUE;
    }

    @Override
    public FileVisitResult visitFileFailed(Path file, IOException exc) throws IOException {
    return FileVisitResult.CONTINUE;
    }

    @Override
    public FileVisitResult postVisitDirectory(Path dir, IOException exc) throws IOException {
    return FileVisitResult.CONTINUE;
    }
    }





    生成ファイルアサーション用のクラス
    importstatic org.junit.Assert.fail;

    import java.io.IOException;
    import java.nio.file.Files;
    import java.nio.file.Path;
    import java.nio.file.Paths;
    import java.util.ArrayList;
    import java.util.List;

    publicclass FileTester {

    private FileTester() {
    }

    privatestatic List<Path> createPathList(String pathString) throws IOException {
    final List<Path> list = new ArrayList<>();
    Path path = Paths.get(pathString);
    Files.walkFileTree(path, new FileCountVisitor(list));
    return list;
    }

    publicstaticboolean exists(String pathString) throws IOException {
    return !createPathList(pathString).isEmpty();
    }

    publicstaticint count(String pathString) throws IOException {
    final List<Path> list = createPathList(pathString);
    if (list.isEmpty()) {
    fail("capture failed");
    }
    return list.size();
    }
    }





    ファイル削除Visitor(テストの後始末)クラス
    import java.io.IOException;
    import java.nio.file.FileVisitResult;
    import java.nio.file.Files;
    import java.nio.file.Path;
    import java.nio.file.SimpleFileVisitor;
    import java.nio.file.attribute.BasicFileAttributes;

    publicclass DeleteVisitor extends SimpleFileVisitor<Path> {

    @Override
    public FileVisitResult visitFile(Path path, BasicFileAttributes attributes) throws IOException {
    System.out.println("delete file : " + path.getFileName());
    Files.delete(path);
    return checkNotExist(path);
    }

    @Override
    public FileVisitResult postVisitDirectory(Path path, IOException exception) throws IOException {
    if (exception == null) {
    System.out.println("delete directory : " + path.getFileName());
    Files.delete(path);
    return checkNotExist(path);
    } else {
    throw exception;
    }

    }

    private FileVisitResult checkNotExist(final Path path) throws IOException {
    if (!Files.exists(path)) {
    return FileVisitResult.CONTINUE;
    } else {
    thrownew IOException();
    }
    }
    }


    そして、これらを使って、JUnitでファイル生成のテストを行うとこんな感じ。





    importstatic org.hamcrest.CoreMatchers.is;
    importstatic org.junit.Assert.assertThat;

    import java.io.IOException;
    import java.nio.file.Files;
    import java.nio.file.Paths;

    import org.junit.After;
    import org.junit.Test;

    publicclass VisitorTest {


    @Test
    publicvoidほげほげなファイルを5個作る() throws IOException {

    // setup
    final String pathString = "usr/local/hoge";

    // exercise (hogehogeなファイルを作る)
    generateFileHoge(pathString);

    // verify (ほげほげなファイルが5個作られているか確認)
    assertThat(FileTester.count(pathString), is(5));
    }

    @After
    publicvoid teardown() throws IOException {
    final String pathString = "usr/local/hoge";
    // 作ったファイルは消してテスト前の状態に戻す
    Files.walkFileTree(Paths.get(pathString), new DeleteVisitor());
    }
    }








    【小ネタ】Bloggerのコメント欄はHTMLがほぼバリデーションで引っかかる

    $
    0
    0




    標題の通り。メモです。




    brタグはOK
    preタグNG
    pタグNG
    bタグNG
    divタグNG
    spanタグNG
    liタグNG
    uタグNG
    strongタグはなぜかOK
    delタグはNG
    &nbsp;はOK
    &lt;はOK
    &gt;はOK



    したがって、コメント欄でジェネリクスとか書くときは
    List&lt;String&gt; list = new ArrayList&lt;&gt;();
    とか書かないとダメなのだ!
    やだっ!

    あと、4スペースとかでインデントしててもトリムされてしまうので
    &nbsp;
    を4回とか。。。

    神クラスにどう向き合うか考えてみる

    $
    0
    0


     はじめに


    最近、仕事で今見ているソースコードが
    めっちゃHogeUtilとかFugaUtilとかだらけで、
    ドメインのプレフィックス + Utilつけりゃなんでも良いのかよ…とか思って考えてます。

    そんで、これはいわゆる神クラスというやつだなぁと。
    そこに立ち向かうにはどうしたら良いのか、
    (どうリファクタリングしたら良いのか、クラス設計したら良いのか)
    みたいなことを考えてみます。









     神クラスって?



    そもそも、神クラスってなんだってところから。
    調べてみると、どうやら語源は
    Object-Oriented Design Heuristicsという本らしいです。


    Object-Oriented Design Heuristics
    Object-Oriented Design Heuristics



    参考URL
    http://c2.com/cgi/wiki?GodClass


    簡単な意味の理解としては、このWikipediaに書いてある神オブジェクト
    とほぼ同じと思って良いでしょう。多分。



    設計の一部分(クラス)に、過剰に機能を集中させること


    Wikipediaより引用


    余談ですが、このWikipediaのアンチパターン集、結構眺めてると面白いですね。



     Utilとはナニモノだ



    JavaにおけるUtilとは多分、
    「処理中にあふれた共通的な処理を集約しよう」
    という意識の表れではあり、インスタンス化不可(privateコンストラクタ)の
    staticメソッドのみを持つクラスです。


    UtilはGoFのデザインパターンには分類されてないようですが、
    Apache Commons由来で広く知られているクラスのパターンです。

    参考URL
    サルでもわかる 逆引きデザインパターン第4章 逆引きカタログユーティリティクラス


     Utilは逃げ場じゃない



    だがしかし、「よーし、お父さんUtilクラス作っちゃうぞー」となるのは
    素直にGOサイン出せないというか。ちょっと待ちましょうか、一旦。と思います。



    Utilは多分もっと明確なクラス定義が必要なんでしょうけど、それがされてないと思うので、
    抽象的なクラスの責務に対して具象的なメソッドが生える場所になってしまいがちです。


    また、共通的な処理メソッド置き場みたいになってしまうところを何度か
    システム開発の中で見てきました。
    クラスに対して実装者が一人ではなく、複数人(5〜6人とか)が付け足していく。
    そうなると、クラスの完全性が伴わずチグハグなものになってしまいがちです。




    そうなると、それはSOLIDじゃないな、と。
    単一責任の原則は守らないと色々崩壊が始まります。



    また、クラス名以上に様々なドメインというか色んな所と依存しあって
    密結合になってしまうこともよくあります。


    こういったことが起こりがちなのは、XXXUtilの他にもXXXHelperや
    XXXManagerといったクラスがあります。




    安易に作ってはいけないと思うのであって、絶対作るなという意見ではないです。

    Utilクラスを作ることを検討するのは

    ・Apache Commonsにないか確認する
    ・状態を持たない処理に限定する
    ・特定の対象(クラス名に含む対象)に対しての操作のみ行う

    場合とかじゃないかなぁと思います。
    Apache Commonsに限った話ではなくて、
    車輪の再発明の可能性も高いので色々注意が必要なとこだと思います。

    日付操作、文字列操作、数値操作のみのUtilならまだ精神衛生上良いです。
    個人的には。

    型名Utilなら、その型のインスタンスを対象とした操作のみに集約されるので。



     クラスの分割



    クラスの分割に際しては、やれるだけやっちゃった方が良いんじゃないかと思います。
    というのも、クラスが小さくてガッカリする人よりも
    クラスが大きくてガッカリする人の方が多いと思うから。


    個人的には1クラスは300ステップぐらいが読みやすいです。
    1kステップとかになってると、どっかクラス設計が悪いんじゃないかなと思っちゃいます。


    分割の観点としては
    ・深いネスト
    ・長いメソッド
    ・多い引数

    とかのリファクタリングから見ていきます。


    そうすると意味のかたまりがなんとなく見えてきます。
    Utilクラスにいるけど、本来はここにいるべきじゃないかな、とか見えてくるはず。
    逆に言うと、デザインされていても良いようなクラスが
    存在しないからUtilになってしまってると思います。




    クラスの分割に際しては、この方のスライドとか僕の考え方に近いなーと思います。

    オブジェクト指向できていますか? - Moriharu Ohzu(SlideShare)
    というか、出典も明確でぼんやり考えてる程度の僕よりも全然立派なものなんですけどね笑


    このプレゼン資料はThoughtWorksアンソロジーという本の規約を忠実に守る感じですね。
    かなり規約でしばってる感じはします。

    ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション
    ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション







     クラスの命名



    正しいデザインが出来れば、Utilの名前も変わってくるかもしれません。
    実際の処理に対して抽象度の高すぎるUtil名(例えばHogeSystemUtilとか)は
    そのユーティリティが何に対してのユーティリティか分かりません。


    そういったリファクタリングからの再設計の検討で
    業務ドメインに落とし込めるのではないかなぁと思います。

    ※汎用性の高い処理は抽象的な名前になるとは思うのですが。




    Parser#parseとかNormalizer#normalizeとか最近は好きですね。
    それだけしか俺はやらんぞって気持ちが溢れてる感じがします(厳密には違いますが)。



     まとめ



    ということで、神クラスって何かってところから始まり、
    神Utilにどう立ち向かうかを考えました。

    で結論としては以下の様な感じです。


    ・Utilクラスは安易に作らないほうが良い
    ・作るとしても命名は気にしたほうが良い
    ・神Utilはリファクタリングから処理を分解して意味のかたまりにする
    ・意味のかたまりが増えてきたら新しいクラスを作るなどクラスデザインをもう一度考える


    作らない方が良いとか、命名規約とかは実装段階での話で
    そういう方向に実装が突き進んで行きそうな場合方向転換することで
    新しい神様を誕生させるのは避けようという自戒というかアレです。

    リファクタリングとクラスの再設計はもうすでにFatなUtilクラスが存在した場合の対処法。


    ということで、僕のプロジェクトでは神はもうたくさんいるので
    リファクタリングから始めようかなぁーと思います。。






    人月の神話とピープルウェアを読んだ

    $
    0
    0


     はじめに



    ソフトウェア開発に関係する仕事をしている人なら必ず聞いたことがあるだろう2冊
    人月の神話とピープルウェアを読みました。

    人月の神話―狼人間を撃つ銀の弾はない (Professional Computing Series)ピープルウエア 第2版 - ヤル気こそプロジェクト成功の鍵

    僕が読んだのは人月の神話の第三版とピープルウェアの第二版。
    (新装版を読んだ人はぜひ、何が加筆修正されてるのか教えて欲しいです)


    普段、そんな本読んでもブログに書こうとは思わないのですが、
    昔から名著として語り継がれるだけあって、ホントに感銘をうけたので
    ブログを書こうという気持ちになった次第です。



    この記事は、内容を要約や解説するわけではなく、
    単純な感想を書くつもりです。
    本からの引用があれば明記するようにします。






     開発に関わる全ての人に読んで欲しい



    読んだ感想としては、こんなに胸にガツンと来る本はなかなかなかった!!という感じです。
    んで、みんな読んでほしいなと思いました。
    読んだ内容からどう受け止めるか、どう実践するかは十人十色でしょうが、
    バックグラウンドとして持っておいて損はないです。

    というかコンテキストとして同じ仕事をする人で共有したいです。

    みんな読もう!


     ソフトウェア工学の重要性



    2冊に共通して言えるのは、ソフトウェア工学の重要性を終始主張していることです。
    色んな本や、議論をネット上で見かけはしますが、この2冊に勝るものはそんなに多くないのではないでしょうか。

    (とはいっても単純に僕の経験・知識が浅いというのもあると思うので、
    ソフトウェア工学語るならこれは読めよっていうのは教えて欲しいです。)

    いずれにせよ、ソフトウェア工学がしっかりと語られているのは古典と言ってもいいような
    こういう本が主なんじゃないかなと感じています。


     インプリメンテーションとアーキテクト



    人月の神話では終始、インプリメーテンションとアーキテクトという2つの視点で
    語られています。システムの完全性なども本書のキーワードであると思います。


    アーキテクトや、システムアーキテクト、アーキといった単語は
    どこかしらで聞いたことがありました。

    でも、アーキテクトって何が正解なのだろう、どういう定義なのだろう
    というのは仕事をしてきて曖昧なままでした。

    そこがスッキリしたので良かったです。

    インプリメンテーション、アーキテクトのそれぞれの担う役割
    コミュニケーションの取り方など根底に持っておきたい考え方でした。




     エンジニアの尊厳を高める2冊



    これも2冊に共通して言えることですが、システム開発に向き合い、
    エンジニアに向き合った2冊です。
    システム開発で起こりうる問題や解決方法のエッセンスがビッシリと詰まっています。


    特に、ピープルウェアに関してはエンジニアをやる気にさせる
    尊重する内容が満載です。

    僕はずっと働きたい理想の会社像が不鮮明でしたが
    僕の潜在的に求めていたのはこういうものなんだなというのが分かりました。




     様々な議論の原点がある



    システム開発について、エンジニアの労働環境についてなど
    様々な場所で議論はやまないですが、
    最終的にはこの2冊に帰結するなぁーと思うことが増えました。

    色々な話し合いをすると「つべこべ言わず〇〇を読め」という人がいますが
    気持ちがわかった気がしました笑




     まとめ



    皆さんの開発の悩みの大半が、実はソフトウェア工学によることが多いです。
    ということで、システム開発に悩んだら、この2冊を読んだら良いです。


    転職してからシステム開発ってなんだろうなぁ…とぼんやり思うことが多かったので
    初心に帰って整理が出来てきています。
    そして最近はチームビルディングとかに興味が湧いてきてます。







    ぼくがJavaとプロジェクト開発をどうやって学んだか

    $
    0
    0






     はじめに



    たまたま、
    「最近CとJavaを勉強しています。オブジェクト指向難しいです」
    という学生さんと話す機会があった。


    もっと学びたいし、身に付ける方法が知りたい。
    現場の感覚を早く身に着けたいって感じのことを言ってた。


    んで、その熱意が結構いいなぁと思ったので、
    一体自分はどうやってプログラミングとかこの仕事に対するレベルアップを図ってきたか
    考えてみよう。ということでブログを書く次第です。




     研修



    前提として、僕は社会人になるまでプログラミングも知らない
    ただの文系大学生だった。

    本格的にプログラミングを始めたのは会社に入ってから。
    多分23歳とかそこらへんから。


    Javaだけ学んだ。基本的な文法、バッチ作成、CSV出力、
    Webアプリケーション改修などといった課題をこなした。

    Javaの入門書一冊を写経しつつ、会社の用意した課題をクリアしていくといったかたち。
    まぁどこの会社でもよくあるであろう。



    ただ、個人的な経験として
    この時の学習効率の良かったと思うポイントとしては、
    周りがプログラミング経験者ばかりであったことで割りとレベルが高かった。
    彼らは今でも優秀だと思うけど、やっぱ同じ学ぶ環境の人のレベルってのは重要。

    あと、基本的に教えてもらうことはほとんどなくて自力で解決することが多かったので、
    ググり力はここで上がった。仕事を始めてからもやっぱググり力は大事。
    現場の人の言ってることより信ぴょう性は高かったりする。(どちらも出典が大事だが)


    もっというと、本読むことで一番信頼できる情報源にたどり着くのだけども。
    その発想はこの当時なかった。


    もうひとつ、個人的な動機付けとしては危機感があった。
    1社目でブラック企業にあたり、退職。単身上京するという背水の陣だったので。
    全てを捨てて挑む気持ちがあった。今はちょっと薄れちゃってるかなぁ。



     社内Androidアプリ開発



    これも個人的には大きかったのだけど、その当時社内で勢いのあった
    「社内Androidアプリ開発」。

    Javaを学び始めた当初から、Androidのアプリは作りたいなーと思ってたが、
    多分自分一人だと怠けちゃって作らないだろうという自信があった。
    チームで作業すれば否が応でも手は動かすだろうなと思って開発に参加。


    はじめは「分からなすぎわろたw…わろた…」が1ヶ月ぐらい続いた。
    Eclipseすら使いこなせないし、ボタン押しても動かないし、xmlでレイアウト作っても読み込めないし。
    点と点がつながらない。線にならないという感じだった。


    この時に意味もわからずinterfaceを使うことで
    使ってるうちになんとなく仕組みがわかった。
    溺れてるうちに泳ぎ方覚えた感じだった。


    当時書いたソースコードを1年後に見たら誰だこのクソコード書いたのは…と思ったけど。



    ここで得たのは、プロジェクトでアプリケーションを開発する、という感覚と
    SwingやAndroidみたいなアプリケーションのなんとなくのパターン。

    UIがクラスになって、インターフェースが発火装置になるみたいなイメージ。
    非同期通信の概念とかも覚えるのに役立った。


     現場デビュー



    研修が終わって仕事に出た。
    なんだかんだ言っても、現場感覚というのは現場でないとつかめないかなぁという感じ。

    ガイド、設計書、方針書。色んなドキュメントがあった。
    へぇー、プロジェクト構成こうなんだー。とか
    これは研修でも使ったやつだなぁとか手探りな感じ。

    ヘマもいっぱいやったと思うけど、なんとなくの周囲の雰囲気で
    アンチパターンは覚えていった。


    例えばSVNのリポジトリは消しちゃダメとか、.svnごとコピーして別のプロジェクトコミットしたら
    大変なことになるとか。


    他方、この時に今でも心の師匠としている人との出会いがあり、
    学ぶことがめちゃくちゃあった。
    だいたいこんな感じ。

    ・仕事は早く終わらせて定時で帰る
    ・進捗ペースを急かさない。見守る
    ・具体的な実装は示さないが、イメージ・アイデアは提供する(選択の余地をくれる)
    ・基本的に楽しそうで雰囲気を和らげてくれる
    ・ユーザーは何が嬉しいか、こうしたいんじゃない?という視点を持ってる



    あと、実装がめっちゃおしゃれだった。
    一番初めの現場であの人に色々仕込まれたのは大きい。
    僕のJava技術者のスタートとしてかなりのアドバンテージになってると思う。




     炎上体験



    まじアンビリーバボー。
    例のごとく、以前書いたブログ記事を引用。
    泥沼プロジェクト振り返り


    当時学んだこととしては
    ・プロジェクトはリーダーとかPMとかが上手いこと進めてくれるものではない
    ・最低限、自分の高稼働リスクは自分自身で割けなければならない
    ・プロジェクトを推進するのはメンバーひとりひとりであり、それが自分である


    みたいなこと。
    これも自分の中で反省材料となって今に生きている。
    (技術とはあんまり関係ないな。どっちかというとソフトウェア工学的な)。




     ぬるま湯



    逆に、めっちゃ暇すぎて死にそうな時期もあった。
    仕事中に暇つぶしする毎日。

    Javaのパッケージの中身をめっちゃ見たりとか
    jdkって何が入ってるんだろう?とか
    Strutsのソースってどんな感じで書いてあんの?

    とかそんなことをしながら暇をつぶしていた。
    んで、この頃ブログを始めた。


    以前よりちょっとJavaと仲良く慣れた感じの時期。





     勉強会デビュー



    丁度1年ぐらい前。


    一気に視野が広がったし、Javaのコミュニティ内での交流も自然と増えた。

    すごい、井の中の蛙だったなぁと思う。

    勉強会やカンファレンスなどに参加して

    ・モチベーションの向上
    ・同じ方向を向く技術者の認識共有
    ・自分の技術レベルの立ち位置の確認
    ・新しい技術、既存の技術の新発見
    ・アンチパターンの再認識
    ・Java技術者のコミュニティ文化を知る

    などが出来た。


    これらも今に生きていて
    自分の中の軸になっている。


    あと、多言語を学ぶきっかけ(もしくは学びたい)というきっかけになってる。



     習熟曲線



    この記事でうだうだと書いてことを(統計屋に見せたら怒られるような雑な)グラフ化してみた。




    研修期間は基礎をしっかりと学べるので学習効率は高い。身につく。
    Android開発はJavaの基礎覚えたての自分には始めが辛かった。
    どこかでコツを掴んでグンと学習効率が上がった。(最近のAndroid全然分からんけど。)
    現場デビューしてからしばらくは学ぶことが多かったが、しばらくすると停滞。
    勉強会デビューして刺激を受けて
    学習意欲が湧いて最近それがやっとoutputとして出せるように
    なったかなぁという感じ。


    こうやって考えると、停滞と上昇を繰り返すものなんじゃないかなぁという
    雑な考察になる。




     まとめ



    自分の体験を振り返って、学びはじめの人に伝えるとすると
    壁にぶち当たることが成長の目印というか。突き抜ける目前まで来てるのだと思う。


    あとは、周りの環境とか人は大事。悪い環境でも活かそうとする姿勢も大事と思う。


    という、ブログ記事を書いてると自分へのブーメランでしか無いなぁ笑


    全然習熟してないです、ぼく!!




    とりあえずResultSet#getStringした時のPostgreSQLのjdbcドライバの挙動

    $
    0
    0






     はじめに



    いやぁ、夏なのに肌寒い日が続きますね。
    そんな日はResultSet#getStringの挙動が気になりますよね。


    JDBCの仕様に沿って、各ベンダーがjdbc実装をしているから、そりゃ挙動も変わってきます。
    なぜかPostgreSQLの数値型をgetStringした場合の挙動を調べたのでメモがてらブログ書きます。






     JDBCドライバの暗黙変換、明示変換



    そもそも、ResultSetというインターフェースは
    各型のメソッドgetXXXを用意してくれてるわけなので、
    数値型をgetStringするのはあまり推奨されてません。

    オラクルであればここらへんとか。



    型変換に関しては徳丸さんの記事が詳しいと思います
    SQLの暗黙の型変換はワナがいっぱい - 徳丸浩の日記


    ざっくり言うと、明示的な型変換をすべし、ですよね。
    あと、型にあったメソッドを使うべしですね。



    なんでもgetStringするってことはjdbcドライバの実装依存となるということ。
    また、型情報のハンドリングを適切にやっていないということになるのではないかと思います。



     PostgresSQLはGitHubにソースがある


    基本的にはResultSetインターフェースの仕様を守るように
    各ベンダーは実装してくれてるだろうとは思いつつ。


    論よりソースということで。



    GitHub上でjdbc実装を公開しているんですね。
    https://github.com/pgjdbc/pgjdbc

    jdbc公開してるのはもしかすると珍しいんじゃないかなー。
    MySQLなんかあるかな?と思って調べたらGitHub上にありました。
    https://github.com/mysql/mysql-connector-j

    ソースの見やすい時代になったなぁ、いやはや。

    他のDB2とかSQL Serverとかあると思うんだけど、みんな各JDBCの挙動とか知りたくなったらどうしてるんでしょう。

    (そんなん気にせずともORMが吸収してくれてるのがもっぱらなのかな)


    さて、 AbstractJdbc2ResultSetというクラスに
    ResultSet#getStringの実装がありました。

    実態はというと、TimeStampは型チェックしてTimeStamp to String変換。
    その他は大体各クラスのtoString実装に依存します。



    つまり

    SELECT -> ResultSetに格納される(多分この時点で暗黙変換されるんだと思う) → getStringで各クラス型のtoStringをリターン




     まとめ



    ということで、結論。

    ・暗黙変換やめよう、なるべく明示変換しよう
    ・getXXXは型に合わせて使おう
    ・PostgresSQLは各クラスのtoStringに依存する(2015/08/29ぼく調べ)


    jdbcの実装はなんだか読んでるとワクワクしますね。




    Java SE 8をジンワリ布教した

    $
    0
    0





    さて、来年にはJava SE 9が出るらしいですが。
    最近、僕のプロジェクトもJava SE 8になりまして、
    普段嬉々としてlambdaとかメソッド参照とか使いたがっている今日このごろです。


    そんな中、ちょっとStream APIの布教活動したよーという話。








    ケースバイケースなので、無理に使う必要はないですが、
    結局Java SE 6ぐらいの書き方でみんな書いてる感じです。





    単純に知らないのだろうなという感じでした。
    知らないというのは


    ・使っているのバージョンを知らない(Java SEの6なのか7なのか8なのか)
    ・Stream APIを知らない

    という感じ。


    話してみてそこら辺が分かっただけでも良い材料になったなとか思います。




    とりあえず、ちょっと複雑なコレクション操作をする要件だったので、
    これはmapしてfilterしてcollectで出来そうだなぁとか
    軽めのイメトレをしました。


    多少抽象的に言うと、
    取得した情報の売り買いの情報を各店舗の各従業員単位にまとめるって感じです。


    DBから取得した時点では売り買いごちゃまぜ。
    同じテーブルに売買の情報が入ってて、売と買の情報がフラグで切り替えられるという
    1レコードで売りか買いの情報を表す感じ。



    まとめるイメージはこんなん。







    ということで、イメトレ完了したので、まぁこれでオススメも出来よう、という感じです。

    ススメルやり方は今のとこ3つぐらい思いつきます。

    1.大勢を集めてデモする。説明する
    2.一人一人にさりげなくススメル
    3.偉い人に打診してStream API使おうぜってプロジェクト規約とかに盛り込む

    で、一番ラクな2をやろうという感じです。
    そんな僕偉くもないし立派でもないし。



    今回はクチコミのイメージで話してみました。
    Aさん「〇〇な処理があって難しそうなんですよね…。ループしてチェックして…」
    ぼく「あぁ、確かに複雑ですね。なんか、JavaにStream APIっていうのがあるらしいんですよ」
    Aさん「なんですかそれ?」
    ぼく「Javaのハチから入ったらしいす」






    口で説明してもいまいちピンとこないだろうと思い、
    JUnitでコード書いて示しました。
    なるべく、その機能をイメージさせるように書きました。





    HogeDao dao = new HogeDao();
    List<Hoge> hogeList = dao.findData();
    List<Hoge> sellList = hogeList.stream() // Stream化
    .filter(hoge -> hoge.getType().equals("売り")) // 売りの情報で絞込
    .collct(Collectors.toList()); // リスト化

    for(Hoge sell : sellList) {
    // 「買い」の情報はない
    assertThat(sellList.getType(), is("売り"))
    }

    ※ちなみに上記コードはコンパイルもテストもしてません(アカン)






    ぼく「こんな感じで動きます」
    Aさん「その…mapってメソッドの中で変数は使えるんですが」
    ぼく「使えますよ、ここはboolean返せばオッケーです」
    Aさん「それなら使えそうですね!」





    実際使ってもらったら、コードレビューの時にはStream APIを使いこなしていて驚きました。
    同じような処理の実装をAさんがStream APIなしで実装していたものも既存であったのですが
    かなり可読性が上がってステップ数も減り、保守性が上がった感じです。






    今回は登場人物は僕とAさんだけで大した話ではないですが、
    「自分だけがJava SE 8の情報を持っている」みたいなところからの
    脱却の足がかりになったかなと思います。

    僕は派手なことは出来ないんで、これからもじみーにこういう
    口コミ作戦で色々広めていければなぁとw

    今回、ラッキーだったポイントとしては


    ・実装の相談を前もってしてもらった
    ・オススメしてそれを上手く取り込むスキルのある人だった
    ・僕の説明で理解してもらえた
    ・特にこだわりなく実践してもらえた


    というところです。


    もっと自分からコミュニケーションをしたり、
    困っていることをピックアップできるプロセス盛り込んだりとかしていかないと
    って感じですね。

    あと、オススメするにも
    ・理解が早そうな人
    ・実践できそうな人

    から優先して地盤を固めていきたいですね。

    秘伝のソースコードや秘伝の運用にへばりついたような人は
    なるべく回避して無難にやる感じで。


    ダメ元でやってみるとなんとかなるもんだなぁ、という話でした。




    長い夏は終わった。KotlinのM13は君に語りかけるぜ!

    $
    0
    0






    ということで、KotlinのM13がリリースされました。

    ほぼ、公式blogのそのまま書くつもりなので、詳細は原文参照のこと。


    Kotlin M13 is out!

    今回の変更は言語の最終仕様の決定と言ってもいいでしょう。
    そして、それぞれユーザーに意見を求めていた結果をフィードバックして、
    言語デザインに反映しています。






    変更をまとめるとこんな感じです。


    ・コンパイラのdaemonがより早くなった
    ・lateinitというプロパティでDIサポート
    ・sealed classで代数型サポート
    ・ターゲットアノテーションのspecifyingとチェック
    ・JavaのGetter/Setterの組み合わせをKotlinのプロパティとして扱えるようになった
    ・アノテーションと修飾子を分割した
    ・Fullly functional Reflection
    ・internalへのアクセスをモジュールの外部で行うようになった
    ・トップレベル関数がktファイル単位でJavaのクラス互換になった
    and more





    言語の最終アップデートがほぼ終わったようです。
    細かな変更はあるかもしれませんが、マイグレーションのサポートはしますよ、と。
    Kotlinの内包するJavaScriptランタイムに関しては実験的な機能追加を考えているが、
    メジャーバージョンリリース後となるとのこと。

    KotlinのJVMランタイムの方はほぼ仕様が固まった、ということだと思います。





    今まで、アノテーションベースのDIと相性が少し良くなかったKotlinですが、
    lateinitにより、かなり改善されました。

    詳しくはたろうさんのblog参照のこと。


    Kotlin M13で追加されたlateinit試してみた- 算譜王におれはなる!!!!



    いわゆるsealedクラスです。
    型によるパターンマッチが出来るので、過去にTupleでKotlinがやろうとしてたことを補うかな。
    まぁ、厳密にはまた別物だと思うのですが。


    こちらもたろうさんなblog参照のこと。


    Kotlin M13で追加されたsealed class - 算譜王におれはなる!!!!




    Kotlinチームはアノテーションと修飾子の分離を考えて、意見を求めていました。
    Modifiers vs Annotations


    今までのKotlinはアノテーションと修飾子は記述的には同じようなものでした。
    (アットマークなしのキャメル記法)。
    また、アノテーションはM12あたりからアットマークをつけるのは言ってたと思うんですが、
    オプショナルなものでした。

    M13からは@がアノテーションには必須となり、今までアノテーションとして扱っていたものを修飾子として再定義したようです。


    Javaとの互換のためのアノテーションは以下のようになります
    @Throws - Javaのthrows
    @Volatile - Javaのvolatile
    @JvmName - Javaでのクラス名
    @JvmStatic - Javaでのstatic


    以下のアノテーションは修飾子に。
    data - dataクラスとかに使う
    inline - インライン化する時に使う
    noinline - インライン化しない時に使う
    crossiniline @inlineOption(ONLY_LOCAL_RETURNS)を変更
    tailrec  @tailRecursiveを変更。末尾再帰最適化
    external  @nativeを変更。Java互換のためのもの


    個人的にはこの変更は分かりやすく良いです。今までは、
    「あれはアノテーションだっけ?修飾子?」
    って感じだったので笑


    変更はIDEがよしなにやってくれるようです。





    以下のアノテーションをサポートするようになりました。
    @Retention 実行タイミング指定、Javaと同じ感じ
    @Target
    @MustBeDocumented  ドキュメントのためのマーカーアノテーション
    @Repeatable  複数回エレメントを繰り返すためのマーカーアノテーション




    class Example(
    @field:MyFieldAnnotation(...)
    val foo: Foo
    )




    M13以前はプライマリコンストラクタで
    コンストラクタインジェクションしなければなりませんでした。
    かなりフィールドインジェクションしやすくなったので
    Jacksonとかも便利に使えるで!とのこと。





    アクセス修飾子の可視性にも変更があったようです。


    トップレベルのprivateはファイル内のスコープのアクセスのみ許します。



    修飾子なしのデフォルトはinternalからpublicへ変更。

    これまで、Kotlinチームはスコープについて悩んでいて、
    ユーザーの意見を取り入れようとしていました。

    結果的にデフォルトスコープをpublicとして選んだのですね。
    Kotlinは型安全な言語で、より安全にするにはprivate。defaultはもう少しロジカルであろう、とのこと。
    だからデフォルトスコープはpublicが妥当だ、という結論みたいです。
    (Javaだとパッケージプライベートですね)

    Javaコーディングでは色んなところでpublicを書くことになる。
    コードをクリーンに保つためにはpublicをデフォルトにしたい!という感じ。

    internalは残ったままですが、デフォルトではなくなったので今後は明示するに必要があります。




    参照呼び出しのオーバーロードサポート。
    関数fooがオーバーロードされたとしても、


    ::foo
    と書けます。


    シグネチャは文脈によって、選ばれる。つまり、実行時の判断ってことですかね…?
    明確なsuper実行はジェネリクスのダイヤモンド無しで実行できる。


    型パラメータの厳密なnullabilityのチェックも出来るようになった
    デフォルト引数のない関数はオーバーロードがやりやすくなった、とのこと。

    @HiddenDeclarationというアノテーションでバイナリを維持しつつクライアントからの宣言を隠蔽出来るようになった。
    うーむ、よう分からん。




    Javaのクラスを読み込むとき、明示的にゲッターセッターを呼び出さなければならなかったけど、今後はKotlinと同様に呼び出せます。
    以下のような感じ。


    // Java:
    class JBean {
    public Foo getFoo() { return ...; }
    publicvoid setFoo(Foo foo) { ... }
    }

    // Kotlin
    <br/>
    fun demo(bean: JBean) {
    println(bean.foo) // 'foo' is automatically defined
    }

    コンパイル時に最適化してるとのこと。


    これで、Javaとの互換性が更に上がりました。やったね!





    Kotlinチームはトップレベルの定義のJava互換に関しても意見を求めていました。
    Improving Java Interop: Top-Level Functions and Properties

    今まではトップレベル関数はパッケージに属していたんですが、
    これからはファイルに属するような形になります。
    Javaからの呼び出しが楽になりますね!

    今まで

    java HogePackage

    これから

    java ファイル名

    大雑把に言うと、こうです。
    また、ファイル名でなくても@JvmName("CustomName") という風に任意にクラス名を定義できるようになっています。


    この変更により、ビルドツールのエントリポイント指定もデフォルトが変わるのでAntやMaven、Gradleは修正が必要です。





    これに関しても以前議論されていました。
    Upcoming Change: More Null-safety for Java


    Javaで@NotNull and @Nullableを使うことが出来ます。
    誤用の場合は、コンパイルエラーではなく、WARNINGとなるらしいです。

    つまりJavaとKotlinのnull安全の距離がグッと縮まったわけですね!


    ArrayListの中身がnullだった、なんてこともなくなる!

    Java側では静的なnullチェックはされないため、
    Platform typesは残ったままです。
    @NotNullと@Nullableが誤用されたりする場合も想定しているとのこと。





    Kotlin周辺のライブラリも便利になったよとのこと。
    functionalにリフレクションが出来るように改善されたらしいです。


    あと、コレクションライブラリとDelegate Propertiesも便利に。
    これは別のブログ記事として公開するっぽいです。




    コンパイラのdaemonが入りました.
    Gradleのdaemonをサポートします。
    これによってパフォーマンスは落とさずにインクリメンタルなビルドが出来るようになった!多分。


    (ここらへん詳しくない)






    とりあえず、急いで書いてみましたが、結構大きな変更もあり、
    そして、仕様が確定してきました。メジャーリリース近し。

    なかでも大きな変更は ・代数型サポート
    ・DIサポート
    ・Java互換性の向上
    ・アクセス修飾子の変更


    といったところですかね。

    Javaとの互換性、ビルドスピードなど
    掲げていたポリシーを貫いている感じがいいですね!

    段々とKotlinは実用的になってます!!!



    第2回関西Kotlin勉強会に参加&発表してきました

    $
    0
    0



    関西Kotlin勉強会に参加、発表してきました!

    connpass.com





    第2回関西Kotlin勉強会で発表してきたよ〜 #ashiyakt - 算譜王におれはなる!!!!
    関西Kotlin勉強会 反省会 - シスアーキ in はてな










    僕の資料です。なるべくKotlinを知らない人にも伝わるようにーと思って
    総括っぽい資料を作りました。

    でも発表資料がコードに少なかったなぁというのはちょっと反省…!





    KotlinでDoma

    backpaper0さんの発表。KotlinでDomaを使ってみたよという話でした!
    最近、Kotlinでもkaptというものを使って、
    pluggable annotation processingを使うことが出来るようになったので
    それを早速利用して…という感じです。

    Javaのannotation processingを利用できるJVM言語は今のところ少ないということで
    客観的にKotlinについて発表していただいたなぁと思います。







    s_kozakeさんの話。拡張関数良いよーって話でした。



    飛び入りで発表してくれたtakuji31さんの発表資料です!
    Shared PreferencesのKotlin拡張ライブラリのお話でした。


    関西でKotlin使ってる人がいるなーとなんとなく知っていたのですが、
    すごい使いこなしてて、羨ましいなぁという笑

    今後もKotlinをガンガン使っていって欲しいです!






    ngsw_taroさんのKotlinでJackson連携をしたはなし!
    JavaとKotlinとの互換性なども踏まえて実際仕事でKotlinを取り入れた一例は貴重だなーと思いました。

    その後に出てきた変態おじさんの話がインパクト強かったですw
    あと、それを実際に実装するたろうさんのライブコーディング力がすごかった。




    昨年も関西Kotlin勉強会は4人か5人ぐらいだったんですが
    今回は15人と結構人数増えて驚きました…!
    それだけKotlinという言語に去年より注目集まっているってことかなぁと思います。

    実際参加された方に聞いていみると、
    「Kotlinという言語は聞いたことはあるけど触ったことはない」
    という人が多かったです!

    こういう勉強会がKotlinを使ってみようというきっかけの一つになればなぁと思います。


    Seasar Conference2015に行ってきました #seasarcon

    $
    0
    0


    Seasar Conference2015に行ってきました!






    何年ぶりかのSeasarのカンファレンスイベントです。
    僕としては確実に一時代を築いたSeasarというコミュニティというか組織?
    の空気感を味わいたいというのと
    今後、どのようになっていくのかということが気になり、今回参加しました。





    今回の大きなトピックはSeasar2のサポートがあと1年で終了するということ。
    今後はSeasar Projectsは助けてくれないわけですね。
    なお、DBFluteはこれからも続くよ〜と、くぼさんが仰ってました。
    Seasar.netは今後も続くとのこと。でも殆どのSeasarプロジェクトは止まってしまうようです。



    【NOTE】追加コメントが有りました!!!
    DBFluteユーザの集い ›Seasarプロジェクトclose予定に向けて

    Seasarの同窓会ではなく、卒業式でした。

    Seasarの次になるものを各自見つけて欲しい。
    ひがさんの口から特定のプロダクトを推奨することはやらない、という感じでした。


    ※追記 ひがさんがブログで公式発表しました
    Seasar2から卒業しよう - DJ HIGAYASUWO (元ひがやすを)
    続・Seasar2から卒業しよう - DJ HIGAYASUWO (元ひがやすを)


    あとは大物のエンジニアがこの先生き残るためには?的な話をしてました。

    また、Seasarから巣立って今はこんなことをしています、
    という色んな方の発表があったと思います。


    SeasarはOSSコミット、コントリビュートの敷居を下げたプロダクトであり、
    多くの優秀なプロダクトとエンジニアを育んだのだなぁと改めて感じました。


    個人的にはDJになったひがさんをあまり感じられなかったのが残念ですw
    (keynoteやその他ひがさん関連のセッションに参加できてないので。
    噂によるとデモとかも無かったと聞いてますが、見たかった)




    もうすでに色んな方が書いてますね。みなさん素早い…!

    Seasar Conference 2015 Not 同窓会 But 卒業式 #seasarcon - Chonaso's Commentary@hatenablog
    Seasarのサポートはあと1年!繰り返すSeasarはあと一年で終わる!#seasarcon - 何か着ていればいいよ
    Seasar Conference 2015 行ってきた - hidekatsu-izuno 日々の記録
    Seasar Conference 2015に参加してLTをしてきました #seasarcon - susumuis Info
    (WIP) Seasar Conference 2015に参加してきた - てんてんのぶろぐ

    以下、それぞれ僕の聞いたセッションを振り返っていきます。





    SmartNewsというアプリは知っていたので、
    Seasarとの関わりが気になり聞いてみようと思いました。
    まだ資料はアップされてないですね(されるのかはわからないですが)。


    今でもSeasarのライブラリはSmartNewsには残っていて、徐々に書き換えているって言ってたと思います、確か。


    浜本さんの自分史的なところを踏まえて、SmartNewsの誕生、それとSeasar2の関係。みたいな話でした。



    ・はじめはバイトで働いていた会社でエンジニアとして就職
    ・一応Javaが得意だったのでJavaでサービスを作る
    ・生Servletと生JDBCでゴリゴリ書いてた
    ・Seasarプロジェクトと、くーすに出会う
    ・ダイコン時代
    ・S2 + S2JSF + S2Daoを使うようになる
    ・Swing上でS2コンテナを使うS2Swingを開発
    ・S2 + Cubby + S2JDBC + S2Flexで
    はてなブログとかのホットエントリを可視化するblogopolis.jpを作ったり
    ・会社辞めちゃって好きなモノを作るようになった
    ・Twitterのクローラーを作り始めた
    ・クローラー技術を活かし、Crowsnestというニュースリーダーを作る
    ・毎月15万ぐらいの出費
    ・出展したブースが圏外でデモできず
    ・圏外でも使えるニュースアプリ、SmartNewsを作る



    SmartNewsってだから出来たのかぁーと納得したのと、
    苦労とともに成功があるなぁという感じがしました。






    jfluteこと、くぼさんのセッション。ライブコーディングがすごいすごいとは聞いていましたが
    ここまですごいとは…という感じで圧倒されました。


    本題としてはSIとスタートアップの比較。それに加えてOSSの話、という感じでした。
    スライドを見ればわかると思いますが、SIとスタートアップを比較しながら話が進み
    深く頷いてしまうような話題が多かったです。


    あと、笑いを取りに行った時に後ろに居たcero_tさんが悔しそうにしてました。


    この方のライブラリやプロダクトの開発スピードやバイタリティみたいなものは
    ホント素晴らしいなと思いました。

    どう経験を詰めばそんなすごい人になれるんだー、という感じですね。。






    nulabさんの雰囲気を感じたいなーと思い、聞きに行きました。
    内容としては題名通り、CIのお話。
    Jenkins、Travis、circle ciなどなど。


    ココらへんの話は僕はとても弱いので勉強になりました。




    まだSlideは上がってないですが、Spring Bootのセッションでした。
    話の内容の4割〜5割はライブコーディング。
    いかにスムーズにSpring Bootでアプリケーションが作れるかがわかる内容でした。

    それに加えて、Seasarからの移行のイメージも示していたのが良かったかなぁと思います。

    他のフレームワークと比較した時のSpring Bootの利点として、周辺プロダクトの充実という言葉が出てました。

    それはNetflixだったりSpring本体のライブラリだったりすると思いますが
    他の便利なLight Weight目指したフレームワークには無いだろう、と。


    以下、簡単なメモ。
    ・Spring initializerでpomは全部作ってくれる
    ・@RestControllerはアノテーションつければそれだけで認識してくれる
    ・メソッドに@RequestMappingすればルーティング出来る
    ・actuatorというものがある
    host:8080/mappings
    host:8080/trace
    host:8080/env
    host:8080/dump
    host:8080/beans
    host:8080/configprops
    などで色々設定値が見れる
    ・remote shellでthreadの一覧とか見れる
    ターミナルでsshで認証→Spring Bootのパスワード入力で対話モードにはいるみたい
    ・@Componentなクラスに
    JdbcTemplateなクラスを@Autowiredしてフィールドインジェクションして使える
    ・@Service @Transactional(readonly = false)でServiceクラスを作る
    ・src/main/resourcesにDDL置いておくと自動で読み込んでくれるっぽい
    ・JUnitのテストは
    @SpringJunit4ClassRunner
    @SppringApplicationConfiguration
    @WebApplication
    @IntegrationTest
    をクラスにつける(ケースバイケース)
    ・@ValueでURLをバインド"localhost:${local.server.port}"でPORTを見つけて設定してくれる






    このセッションもすごい面白かった。それに僕にはすごい響きました。
    スタートアップ、SI、受託。それぞれの間の話というか。
    色々経験してたお三方だからこそ出てくる経験則が話されました。


    ※ここで書くのはあくまで口頭ベースのやり取り、ディスカッションを
    僕が勝手に解釈して箇条書きにしてます


    はじめはプロダクトのアンチパターン的な話。

    ・アイデアあるんだけど、やってみない?のパターンはよく失敗する。
    要件、仕様を満たすことを優先してしまい、サービスとして優れているかというところをスキップしてしまう
    ・これ面白そうだなーという、ぼんやりしたイメージで参加すると失敗する
    ・◯◯のスマホ版作ろう!も失敗しやすい
    →プラットフォームを変えて移植版を作るだけでうまくいくという判断が良くない。
    同じ発想の人も多く競争が激しくなる
    ・SNS + なにか。音楽 + SNSとか、趣味 + SNSとかも失敗する(受託)
    ・作ってみてからユーザーの反応を見ようだと失敗しやすい。ユーザー層は予め決めておく必要がある


    他の方のツイートでもこんな風につぶやかれてますね。

    ・技術的負債と企業の技術ノウハウ蓄積の関係の話。使い続けている技術が古い技術とは限らない




    続いて、受託やSI、スタートアップと顧客との関係の話。


    ・受託にもやって楽しい受託と楽しくない受託があった。
    ・仕様書が降ってくる請負、コンペにかけられる請負は断ってやっていなかった。
    こうした方が良いという議論ができる顧客を選びたかった
    ・自分たち → システム部 → ユーザー
    となるとシステム部がプロジェクトのスタイルを強要してしまう
    ユーザーの本当に欲しいものと乖離する
    ・案件が怪しいと思ったら事業計画を見してもらう→事業計画に対して意見交換→受託するか決定する ・顧客といい関係を築くためには… 
    スタートアップだ、受託だ、というのはあまり関係ない。 それよりはチームや人数の規模、情報交換の仕方が重要。その点が大規模なSIだと難しい一因というだけで形態は本来的には関係ない、と


    今回の話の内容では二次請け三次請けみたいな多重請負の話は出ませんでした。

    そこらへんは僕も感じましたし、Twitter上でもこんなつぶやきが目に入りました。






    そして、ゆるーくLT大会が始まりました。
    運営の人のさじ加減次第で制限時間が伸びたりスッパリ切られたりw

    内輪といえば内輪なんですが、そこらへんがアンフェアだと感じる人も中にはいるかもしれないですね。
    ぼくは雰囲気が楽しかったので良かったです。

    それに発表内容や場の雰囲気で判断してたのでうまく回っていた?と思います。

    みなさんのLTはこんな感じです!(見つけられてものだけ記載してます)

    Seasar2で作ったIE8互換の統合基幹業務システムを最新のChrome/Edgeで動作させるための10のクロスブラウザテクニック
    Seasar conference 2015 sa-compojure

    この他にはmayaaの使用例、コミッターへの感謝のLTをいしがみさんがしていました。
    Seasar Conference 2015 LT Mayaaを使ったデザイナーとエンジニアのコラボレーションが超成功するただ一つの方法
    その後にわたなべさんがLTしてmayaaをdisってた気がしますがw
    原爆先生というNPOの運営の話もありました。こちらは原爆の話を学生に伝える授業をしてくれる団体です。
    http://www.social-action-ring.org/detail/detail-1357/





    今日一日でSeasarというコミュニティ、OSS、コミッターやそれに関わる人が
    分かったような気がしました。確実にSeasarは一時代を築いていたんだなというのは
    その当時を知らない僕にとっても納得出来ました。


    それを裏打ちするように、Seasarの各Projectのコミッタは
    いろんな方面で現在も第一線にいます。


    また、SI、受託、スタートアップを改めて考え
    自分に当てはめることが出来たので良かったです。




    僕も守りに入らない、ぞ!


    Viewing all 398 articles
    Browse latest View live