ITコンセプト "enlighten" と第一弾OSS "DomainDictionary" を作りました

というのは若干ウソで、現在進行形で開発・拡張をしています。

enlighten

f:id:saikou9901:20171206222241p:plain

  • プロジェクトページ

enlighten | Information Technologyの新しい視点を

github.com

enlightenはコンセプト、github上のorganizationです。

自分自身SEの仕事をしている中で、アイデアや考え方をこのコンセプトに落とし込んで、それをなんらかのアプリなりサービスなりの形で提供できればと思い、まずは1つの指針として立ち上げました。

このorganizationの中で、オープンソースの形でアプリ開発をしていきたいな〜と。 何の見返りも求めない、システムインテグレーションの助けになるように、貢献感、満足感のためだけのコンセプトです。

ロゴも何もないイメージだけの状態ですが、気長に育てていけたらと思っています。

DomainDictionary

github.com

  • ライブデモ

https://domaindictionary-demo.herokuapp.com/

enlightenのアプリケーションの第一弾として、DomainDictionaryというアプリケーションを作成しました。 名前の通り、業務上のドメインの情報を登録・管理するアプリケーションです。

私のように隔離された開発環境でも利用できるよう、イントラネットワークでも利用できることを大前提としています。 そのほか、enlightenのアイデアに則り、シンプルにすること、依存性のない独立した形にすること、利用負担のないようにすることを考えつつ日々開発しています。

最初のバージョン(v0.1.0)リリースと同時に、私自身も、自分だけの範囲ですが利用を始めています(ドッグフーディングというか、自分がこういうの欲しかったので)。

もしご興味がありましたら、ぜひ皆さんのサーバにこっそり配置して、こっそり使い始めて見てください。

今使い始め、登録されたデータも、バージョンアップにあわせてマイグレーションするように考えていますので、ご安心ください。


今生も一生がんばるぞい

Spring Fest 2017 に参加してきたのでまとめ・所感

11/24(金)に行われた「Spring Fest 2017」というイベントに参加してきたので、 自分が聴講したセッションのアバウトな内容と、自分の所感まとめます。

springfest2017.springframework.jp

セッション内容もある程度記載しているので、ちょっと長文です。


What's New In Spring

twitter.com

内容

最初はSpringFramework全体と、その中でのSpringBoot、SpringCloudの位置づけの話。 SpringはMVC、Security、Dataなど、システムで必要な機能をすべて賄えるほどの大量のプロジェクトがありますが、それを一括管理して省力で利用できるようにするのがSpringBoot(この説明はわかりやすかった)。

セッションの中心は、Spring 5.0 から新しく入るReactorAPI(WebFlux)の説明、デモ。 主にMonoを返すRestControllerを作る感じ。

「今までのブロッキング・同期のコードをほとんど書き換えず、dependenciesとちょっとした変更でReactiveにできる」というのが一押しポイントだったよう。

あと、SpringBoot 2.0、そこに対応するSpring Cloud finchleyは2018年2月ごろになる模様。

所感

SpringBootの役割を再認識できたことは、ためになりました。 RxJava、Angular、AngularMaterialを触っているおかげで、Mono/Fluxの理解がそれなりにはできたかと思います。

Introduction to Spring WebFlux

twitter.com

内容

www.slideshare.net

WebFluxを、デモアプリケーションも含め実装レベルで深く掘り下げた内容。

所感

コンテンツ量も多く、スピードも速かったですが、 これもストリームの事前知識があったおかげで、十分メモを取りながら理解できました。

特に勉強になったのは、次の2点です。

  1. 「WebFluxを使うときは、必ず最後まで”ノンブロッキング”で処理を書かなければ意味がない」ということ。 スレッドが1つなので、完全にリクエスト処理が止まる。

  2. JDBCは完全にブロッキングなので、現時点ではWebFluxと組み合わせることはできない、ということ。 Javaで今後非同期APIを検討中とのことなので、それの先行きを見守るしかない(スライド P.129)

Wagby R8 と Spring の関係

twitter.com

内容

Wagbyという名前は初めて聞きましたが、ノンプログラミングで業務システム開発ができるプラットフォームのようです。

wagby.com

製品紹介は一切なく、内部で使用しているSpring Frameworkのノウハウをひたらすらお話いただきました。 とても潔くてステキ!

新バージョンのWagby8からは次の3つを新たに取り入れるとのこと。

  • Boot
  • Session
  • Security

ぞれぞれ次の通り。

  • Boot

マイクロサービスを目指すために導入。

エンプラアプリケーションでは、特定の機能をある一時期だけ大量に使用する、というケースがあるが、このときVMのリソース定義を最大値に会わるわけにはいかず、平均値にしたところで高付加時に対応できない。マイクロサービスにすることで、アプリケーション分割=リソース定義分割をしたい。 あとはよく聞く、部分変更のために全アプリダウンを発生させないようにするため。

また、パッケージとしての将来性のため、時代に合わせた対応をしたいとのこと。

  • Session

これまでは単一セッションであったため、1ブラウザにつき1タブしか開かないでください、とお客様にお願いしていたとのこと。 これをマルチセッションにするために導入。

具体的な対応を説明いただきましたが・・・一応抽選のランチセッションだったんで、ここに書いてもいいんだろうか? お弁当だけ抽選だからいいのかな?

簡単に、マルチセッションの仕組みは、Gmailに倣ったとのこと。

セッション情報をRedisに保存するために、運用プロセスとしてRedisの管理が増えたが、これはシステムを「前進」させるために必要なこととして、お客様に説明するとのこと。

  • Security

セキュリティ周りが独自実装であったが、認証方法や暗号方式などついていくコストが大変なのでSpringに乗っかる方向に。 おかげで、LDAP認証とDB認証の組み合わせや、BCryptの導入などができるようになった。

エンプラ系システムだと、やっぱり枯れた技術のほうが求められがちだが、新しい技術をエンプラ系システムに適用していき、未来に繋げたいとのこと。

所感

最新技術の勉強会で貴重なエンプラ立場話。 弁当ほしさに聴講しましたが、SIerとしては聞き逃せない話でした。

エンプラ系システムを使って実現される業務を未来に残すためには、やはり新しい技術にアジャストしていくことを絶やさず、それをちゃんとお客様に説明して理解してもらうことが大切です。 開発側の都合に聞こえるかもしれませんが、数年、数十年単位で見て、双方の幸せにつながると思います。

・・・油断するとエンプラシステムに対する熱い(キモい)想いが溢れそうなので、いったんここまで。

Spring Data REST を利用したAPIの設計と、作り直しまでの道のり

twitter.com

内容

www.slideshare.net

オチはP.45から。 Spring Data JPAを試しに使って、使いどころを実感したという話。

所感

2つ後のカサレアル多田さんの話と合わせて、Spring Data JPAの尖ったパワーをよく理解して、よく検討することが必要なことがわかりました。 あと、今回の話では、方針を決定するための「勇気」も必要なことを感じました。

脆弱性の探し方 ~発見と対応のノウハウ In NTTDATA~

twitter.com

内容

TERASOLUNAの中の人が、TERASOLUNAにおける脆弱性にどう立ち向かっているかという話。

2014年にStruts1の大きな脆弱性が発見されてから、脆弱性にいち早く対応するために、脆弱性を「探す」ということに重点をおいて活動している。 大きく、

  • OSSコミュニティなどでの、脆弱性情報や世間に出回っている攻撃コードの情報収集
  • 自分たちのコードだけでなく、依存するライブラリも含めたコードレビュー(※)

脆弱性というのは、基本的には

  • 設計の不備
  • プログラムの不具合

であるため、効果があるとのこと。

脆弱性に関するノウハウ。

プログラムに脆弱性があったとき、依存ライブラリがあったとする。依存ライブラリに脆弱があるときは、依存先が悪いと判断できる。しかし、依存先が「○○で回避できる」と公表していると、それに対応していない依存元プログラムが悪いことになる。それも考慮して実装を検証する。

  • "いつ"脆弱性が作りこまれるか:

依存ライブラリなどがアップデートされた場合は特に注意。脆弱性の3分の1は機能追加・アップデート時に作りこまれる。

ライブラリ呼び出しなどのモジュール間。 Spring MVCとSpring Securityの間では、URLをベースに設定が作りこまれるため、Secruity側でURLパターンの漏れがあれば、脆弱性になる。

ほかのOSSで発見された脆弱性を、Springなどでも横展開調査している。

といった活動により、NTTDATAで、高い割合での脆弱性報告の実績がある。

また、脆弱性を「報告」する際には、悪用されたり、事前察知⇒攻撃、とならないように、 IPAが公開している 早期警戒パートナーシップ などを参照し、 しっかりと警戒しながら報告・対応を行うことが必要。

所感

エンドユーザに近いエンジニアとして、セキュリティに対しては正しい知識が必要です。 また、こういった話を聞いてて多くの人が「セキュリティ広すぎてわからん。一人じゃできない。」と思われると思います。

その通り、「セキュリティは一人ではできない」ということは、セキュリティ関係のコミュニティは共通認識です。

多くのエンジニアがセキュリティに関心を持ち、その知識・ノウハウを共有していくことが大切だと思います。

なので、上記内容記載も長文になりましたが、極力浅く広く記載しました。スライド公開されてたらうれしいんだけどなぁ。まだ見つけてない。

Pivotal認定講師が教える!Spring Data JPAによるデータアクセス徹底入門

twitter.com

内容

www.slideshare.net

Spring Data JPAに関する詳細な解説と、様々な注意点。 まず必要なことは、スライドにもありますが次の通り。

多田さん「次の3つの条件を、すべて、ANDで満たせないと、Spring Data JPAを使うことはおすすめしません!」

  • DBが新規設計できる
  • 集合演算、FROMでの副合わせなど、複雑なSQLがない
  • パーフェクトJavaEE読破者が一人以上必要

多田さん「特にJavaEEJPAの章が必要。JPAに詳しくないと、必ずトラブる!」

所感

2つ前の、楽天の高橋さんのセッションでもありましたが、やはりSpring Data JPAは曲者な模様。

Pivotal認定講師の言葉を信じましょう。 そして、認定講師のセミナーを受けましょう! (宣伝したのでインセンティ

Spring と TDD

twitter.com

内容

最初に断っておくと、JUnit含めあまりテストを書いたことがないため、内容はよく理解できてません。。。

TDD(テスト駆動開発)は、テストを最初に書く⇒次に実装を少しずつ書きながらテストを少しずつクリアしていく、という手法。 実装がない状態からテストを書き始めるので、

  • いかにテストコードを早く書くか
  • いかに最小限のクラス実装で通過できるテストスケルトンを用意できるか

が大事になる。 これを、SpringBootでは、依存先にspring-boot-starter-testを追加するだけで、いろいろ用意してくれている。 アノテーションだけ、レイヤごとのスライステストなど、いろんなテストができる。

MVC、Secrutiyのテストに

@WebMvcTest
@WithMockUser

したり、e2eのテストには

@Autowired
WebDriver

したり。

RestClientのテストには、

@RestClientTest

を書くと、MockRestServiceServerという相手先APIのかわりができる。

@DataJpaTest

を書くと、EntityManagerのテストモックが利用できる。

Boot2.0からは、ConfigurationのBean設定をテストする ApplicationContextRunner という機能も増える。

所感

相手先業務システムを開発する際は、テストコードを書く機会というのは本当に少ないです(現に私は一度もないです)。 個人プロジェクトなどで積極的にテストを書いていきたいですね。

また、情シスなど維持管理になると、今後はでは自動テストは避けて通れないため、そういう意味でも、早いうちに練習をしておきたいですね。

Spring Boot と Spring Cloud で始めるマイクロサービス

twitter.com

内容

まず、マイクロサービスは、特にアメリカで、

ビジネスの仮設⇒システムを少し修正⇒すぐためしてフィードバック⇒仮説・・・

というビジネスイテレートを早く回すために発生したもの。

なので、すべての会社のシステムに適しているかというとそういうわけではなく、全てのアプリケーションがマイクロサービスになる必要はない。 ガートナーだって「企業の8割9割はマイクロサービスを始めて、すぐやめるだろう」と言っている。

そもそも、理想的なマイクロサービスを実現するためには、次のような要素が必要。

  • 分散システムの知識
  • DevOps
  • 可用性、耐久性
  • ドメイン駆動設計の知識(アプリケーション単位などを決めるためには必要)
  • チーム・組織(アプリケーション毎に責任を持つ)

特にチーム・組織作りは、エンプラ系で、エンドユーザとの間にSIerなど挟んだとき、 その仲介がマイクロサービスやそれに合わせた組織作りの知識がない場合がある。

だが、マイクロサービスを学ぶことで、開発者として知識・視野が広がることは確かであるため、学ぶことは開発者として身になる。

その学びのスタートラインとして、Spring Boot + Spring Cloudの組み合わせは、シンプルでちょうどよい。

※Spring Bootの解説がありましたが、この記事では割愛します。

マイクロサービスを構成するとき、

  • どうやってマイクロサービスをさがすか?
  • サービスがスケールアウトしたら?
  • サービスの一部がダウンしたら?(monolithicなら副系切り替えなどするが・・・)

といった課題がある。これらを解消するために、サービスディスカバリなどのデザインパターンがある。それを実現するのがSpring Cloud。

例えばサービスディスカバリには、Netflix OSSのEureka(谷本さんは”ユーレカ”って読んでたかな?)を使用している。

SpringBoot+SpringCloudのシンプルな構成でマイクロサービスを学んで、 技術的視野を広げよう。

所感

マイクロサービスを学ぶと、自然と可用性やレスポンスなどを意識するようになるので、単一のアプリケーションプログラムだけを学んでいるよりも広い視野になることは、確かだと思います。 いわばエンプラ系でシステム全体の構成を考えるイメージに近いです。

どのノードにどのアプリケーションを置くか、ということも考えるようになるため、物理距離やリージョンなど、インフラレベルの現実の制約を意識する機会も増えます。 ただひたすら与えられた業務画面プログラムだけを組むだけでは見えなかった、誰も教えてくれなかった、必要な現実に目が向くようになってきますので、書籍を読むだけでも勉強することをお勧めします。

少なくとも、自分はそうでした。


全体的な所感

エンプラ系のSEなのでその目線で。

総じて、様々なアーキテクチャ・技術を "適材適所" で用いることが大切です。いわゆる無銀弾です。

マイクロサービスの採用/不採用、アプリケーション間連携でのWebFluxの採用/不採用、Spring Data JPAの採用/不採用・・・

Springは本当にシステムに必要な機能をすべて賄うだけのいろいろ機能を提供しています。 実際にそれを使用する私たちSEに必要なのは、適した組み合わせ で取捨選択し、 それを 適した使い方 で価値のあるシステムに加工・組立することです。

再発明もはなはだしい感想ですが、現にそのことを改めて実感した一日でした。


おまけ

最後に、懇親会中のLTの内容を覚えてる限り書きます。

1

DocurainというサービスをSpring Boot+Kotlinで作った際のノウハウのお話。

site.docurain.jp

内容は・・・うっ頭が・・・(記憶がない

2

JUnit5を使ったという話。 kazuki43zooさんの記事がわかりやすいという話。

qiita.com

JUnit4との互換性には注意しましょうという話。

そして・・・うっ頭が・・・

3

Java2年目の女の子が、がんばってJava SE 8 Silverをとった話。

自分の勉強は当然として、社内勉強会を実施して社員間で教えあうことで、合格できたという話。

会社名は・・・うっ頭が・・・

www.stylez.co.jp

4

JavaログにUUIDを出力するMavenライブラリを作りましたという話。

うっ頭が・・・(早い

5

さいぼうずのひとがJDBCTemplateをラッピングしたライブラリを作りましたという話。 MyBatisでもいいけど、クエリを別ファイルに書きたくないから、 @Query("SELECT ...") ってできるようにしました、という話。

うっあt

6

このひとかな?

twitter.com

転職したら使用するSpringが3まで若返ったという話。 JSPがいやだったので、わざわざJARをダウンロードしてThymeleafをいれたけど(Mavenもなかった) だれもThymeleaf読めなくてコードレビューしてもらえなかった話。

うっ頭が・・・(悲しい話のため

7

アニメカバレッジ90%だというこの人。

twitter.com

とても真面目でとても素晴らしい内容の話を聞きました。

それは・・・うっ頭が・・・

8

建築とマイクロサービスは似てるかも、という問いの話。 マイクロサービスのような建築は、40年前からあった。 中銀カプセルタワービル という、同じ形の部屋カプセルを組み合わせた建物。 でもこれはマイクロサービスの悪い例だった。

これまでカプセルが一度も入れ替わってない、なぜかというとカプセルを上から外していかないといけない。つまり、依存性が強すぎる。 配管は奥まって修理困難。 耐震強度の問題で建て替えが必要になってきているが、住んでる人や、芸術価値を感じてる芸術家が反対してなかなかできない。

やっぱりシステムはスモールスタートがいいね。 また、システムをつくるときは芸術重視、効率重視、など目的をもったほうがいい。


内容は以上です。

参加者はどのくらいいたのかな?

次回も参加したいです。

そのときはSpringのステッカーとかほしいな。


あと、東京はやはりいろいろあってうらやましい。

SEとしてただ一つ必要なことに気づいたけど、今まで誰も教えてくれなかったので自分で書きます

ということで書きました。

speakerdeck.com

社内で話す目的で書きましたが、とくに守秘する必要のあるものでもないので、ここで先に公開します。 俺が書いたんやで、という意味も込めて。


キモい話

こういう内容を周りの人に話したりしてると、「意識高いなワロタw」って確実に思われてる思うんですが、私の意識が高いんじゃなくて、どうも今の瞬間しか見てない人が多すぎるというのが正解です。

システムエンジニアリングはサービス業です。第一次、第二次、と数えてかなり後の次元の産業です。

そのシステムを使用する影響は、その前の次元の産業、そしてそこで働く人たちに影響を与えています。 システムを運用するとどうなる、運用した企業はどうなる、その企業がもたらしていた効果はどうなる……。 言い換えると、「意識が高い」のではなく、より「現実を見ている」と言い換えられます。

過去に起きた現実、それをしてきた人の知識・経験を知ることで、同じ失敗を踏まないように、より発展させられるように勉強するのが基本です。 本を読んだり、ネットで調べ物をしたり、考察するということはそういうことです。

ツイッターでもボソッと言ってますが、

これが、たぶん今後の私の命題になってくるんじゃないかと思います。

歯車のように生きれば楽だとは思いますが、まぁやれるだけがんばっていきたいです。

あと、会社員なので、もっとお給料ほしいです。

真・なぜ誰もこう書いてくれないDependency Injection入門

書きました。

speakerdeck.com

主旨は無印版と同じです。

前回の記事は明らかに手抜きすぎだし、実装部分をわかり易くかみくだけてないので、ちゃんと自分で一から書き直しました。

口頭で発表する予定がないのでリハーサルとかしてませんが、実際やると15分ぐらいはなるのかな、と思っています。

口頭説明なしでもわかるように頑張って書いたつもりなので、拡散なりフィードバックしてもらえるととてもうれしいです。