まこたん(makotan)の日記 このページをアンテナに追加 RSSフィード

makotangmail.com   

 

2016-05-28

Reactorはじめました

世の中では同様の物としてRxJavaとかakkaが流行ってるのは知ってるけど敢えて外したw

RxJavaはあんまり惹かれるタイプじゃなかった

akkaはあれやるならElixirで本家を楽しんだ方が良いな〜と見てて思った(Javaで頑張って複雑度が増してね?って)

ということで、色々探してるとhttp://projectreactor.io/を見つけたのでトライしてみようと

(joobyのmoduleにあったから興味がわいたのも一つの理由)


で、始めたのは良いけどいきなり躓いたw

とりあえずFluxとMonoとSubscriberを軸に見て行くとよいっぽい事が判った。

あと、オフィシャルマニュアル風なのは欲しい情報が無いこともあるので、githubに行くと欲しい情報がゲット出来ることもある


joobyとreactor.ioと あれとあれとあれ を組み合わせたら楽しそうだなぁ・・・って想像してるところ

2016-05-14

DIとAOPが面倒になってきたのでまとめを更新

プロダクト DIコンテナ 通信部分 Annotation 特徴
Spring MVC Spring Servlet 独自Annotation オールインワン
JAX-RS CDI/Spring Servlet JavaEEのAnnotation CDIかSpringとの組み合わせが事実上必須、複数の実装から選べる
Ninja Guice Servlet Annotationなし オールインワン
MSF4J DIなし netty JavaEEのAnnotation
SparkFramework DIなし Servlet(Jetty) 独自Annotation
RESTX DIなし Servlet JavaEEのAnnotation
Vert.x DIなし netty Annotation無し 全力でasync
Lagom 不明 不明 Annotation無し Playベースのオールインワン
Ratpack DIなし 不明 Annotationなし Spring-extensionあり
jooby Guice netty/Servlet Annotationなし moduleベースで好きな機能を組み合わせる

AOPが面倒なので、AOPに依存しない事を考えつつ

起動とかが重そうな物をさくっと排除しつつ

実装する側が大変になりそうな物を排除すると

まだ1.0になってないけどjoobyは良い選択かも知れない

ま、過去の利用実績が云々いう人たちには絶対使えないけどw


それにしてもAnnotationProcessorベースのAOPって無いのかなぁ〜

って考えてたある日のこと

2016-05-12

DIとAOPが面倒になったのでLagom

このシリーズ終わりにしようと思ったらいくつか見つけてしまったので、チョット復帰

Lagom Framework - The Reactive Microservices Framework

ここ最近の流行キーワード満載系ですね

といいつつ、これPlayをベースに作ってるの特徴はPlayとよく似てる

Cassandraが組み込まれてるオールインワンという感じ

なんだか・・・重そう・・・(動かす気が起きないw)

DIとAOPが面倒になったのでRatpack

だいぶ前にWebFramework探ししてた頃にも見つけててすっかり忘れてたRatpack

Handler形式で実装するタイプなのでテストとかのAPIを作るのにはとっても楽で良いかもしれない

メインで使おうとすると、周辺ライブラリの量でちょっと残念な感じになりそうな気がした

ratpack-spring-boot extension !?

DIとAOPが面倒になったのでjooby

ほんと偶然見つけたまだ1.0にもなってないもの

Scalable, fast and modular micro web framework for Java.

Jooby keeps it simple but yet powerful.

思いっきりfullstackを目指して絶賛開発中

モジュールの数も既に相当量が用意されてる

GuiceがDI機能としてあったり、Routeの情報をコメントとセットでswaggerとかに出せたりと、チョットしたことだけど作ってるとそれ欲しいよなぁ〜ってのがmoduleとして普通に用意されてたりする

まぁmoduleの大半は外部のComponentをmodule化したものなので、詳しくはそっちみてって感じかも知れないけど

auto-reloadが既にあったりと個人的には注目プロダクトで調査中

2016-04-29

SIerのガンは営業だという仮説

例えば、ある企業が社内に必要なシステムを独自開発したいと考えたとする。


Aパターン

知り合いの会社、知らない会社などに声をかけて説明をして提案を受ける

提案内容から取捨選択して一つの会社に決めて開発する

ここでエンジニアは営業の裏方さんで登場する以外は全く登場しない


Bパターン

独自にエンジニアを募集(ただし社員じゃ無い)して自社で開発をする

来るのはエンジニアだけどシステム開発の経験と知識が自社に無いと無理なパターン


Cパターン

独自にエンジニアを募集(社員)して自社で開発する

エンジニアを採用するのでその後のコストと開発速度(開発時が一番人力が必要だし)は延びる


Aパターンはさておき、BパターンとCパターンの日本での実現可能性を考えてみる


Bパターンは自社で自社の管理下で開発するにはそれなりの技術知識とPMの能力がそもそも自社に備わってないと相当大変、それ以前にエンジニアの能力をちゃんと見極め出来ないと開発が前に進まない

Cパターンはエンジニアを社員として採用すると日本では何かない限りクビに出来ない

ということで、BとCはソフトウェア開発を自社でやるという相当な覚悟を持った経営者が必要になる。

結構大きい会社なら相当人数のエンジニアを常時抱え込めるけど中小にはまず無理だなぁ〜という感想


そこでAパターンを選択する事になる

何を作りたいか決めて、提案を受けて・・・の流れはエンジニアが入った時点で既に色々決まってる。

エンジニアが新しい知識でベストな選択をしたくても、既に決まってることは覆せない

変えるべきはエンジニアの技術力とかじゃなく、営業活動じゃないのかな。


そんなことを思ったある日のランチでの隣のおじさん同士の会話でしたとさ。

2016-04-21

言語からVMの戦いへ

ってタイトル書いてみたかっただけなので、あとはいつも通りな感じ


10年くらい前はJavaRubyPHPの3大勢力+独自規格のC#で争ってた感じだったのが

いまや、いくつあるんだ??位の状態になってきた(といってもSQLがデータ処理のDSLの地位を完全に確立してて変化してないのは面白い)

ざっくり大きく分けようとするといきなり足回りのVMが出てくることに気がついた

  • JVM
  • CIL系
  • js系(WebAssembly系)
  • 独自VM
  • (LLVM系)
  • VM無しのネイティブ

で、さらに今後とも増えていく事が予想される新しい言語と足回り。

JavaCOBOL化の流れは揺るがないとしても最近のOな会社の妙な動きから脱JVM化の動きが出てくるんじゃ無いかという想定を始めたところ

そうしたときに残る選択肢はjs系(WebAssembly系)とCIL系かなと。あとはネイティブへの回帰現象


個人的にはWebAssemblyの動きが気になるなぁ〜と

WebAssemblyだけバイナリの規約なので、WebAssemblyを単なるバイナリ規約として見たときに別のVM上で動作しても良いような気がする(すでに複数あるわけだし)

で、browserでも動くしCILでも動くとなったら、CILがマルチプラットフォームになってる時点で一般的なアプリケーションは全部WebAssembly系に統合されてしまいそうな夢を見た

クライアントアプリはブラウザを囲い込んだだけのやつとか今でも多いしなぁ〜


JVMGCの安心感をどのVMが最初に超えるのか(MSかGoogleになるという予想)

高度なGC作るのがそんなに難しくない言語を新たに作れば良いと思うんだけど、使う側のエンジニアの負担が大きいかな〜

 
東京の天気予報
-天気予報コム-
<< 2016/05 >>
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31

makotanのアンテナ

1. 「Teeda」を含む日記
2. 「S2Tapestry」を含む日記
3. 「Dolteng」を含む日記
4. 「S2XWork」を含む日記
5. 「Seasar」を含む日記
6. 「S2Container.NET」を含む日記
7. 「Aptina」を含むブログ
8. 生駒日記
9. 「s2dao」を含む日記
10. Unofficial DB2 BLOG
なかのひと あわせて読みたい