Logic Delight

明日のワシは忘れてしまうから、コードにはコメントを書くのです。

んなことやってる場合かというタイミングに限ってやる気が起こる

今さらVim

オジサンが何を今さら的なタイミングであることは重々承知の上で、Vimの練習を開始した。

Windowsでは、TeraPad→某有名エディタ→サクラエディタ→SublimeTextと色々なテキストエディタを渡り歩いてきて、どのエディタにも満足はしているが、Macでいい感じのヤツに出会えず、SublimeTextとGoogle日本語入力の相性の悪さ(サジェスト機能を選択するときのTabキーとかEnterキーがエディタ側に誤検知される嫌な感じ)がどうにも解消できず、彷徨い歩いて行き着く先の現在候補がなんとVim、と。

Unix/Linuxの環境ではそれなりにviの基本機能は使って最低限の編集操作はできていたのだが、今度目指すのはそんなのではなく、いわゆるVimmerっていう領域を夢見て。。。

とりあえず、MacVimのダウンロードとインストール

splhack/macvim-kaoriya
https://github.com/splhack/macvim-kaoriya

うん、簡単な動作確認がてら、Google日本語入力との相性(Tabキーで変な動作として拾われないか)とか試してみた限りはいい感じいい感じ。次に、チートシートの印刷。

vim-cheatsheet.pdf
http://www.namaraii.com/files/vim-cheatsheet.pdf

んで、チュートリアルを最初からトライ!←今ココ

チュートリアルvimエディタの使い方を覚えよう — 名無しのvim使い
http://nanasi.jp/articles/howto/install/tutorial.html

よし、この調子で全てひと通り終えた頃には、噂に聞く「3倍コーディングが速いVimmer」になれるのか?!そもそも、そんなことしている場合なのか!?

画面外のウィンドウを戻す技 windows7

先日、これでオタオタしてしまったのでメモメモ。

画面外のウィンドウを戻す技 windows7 | 今日覚えたことの覚え書き
http://xn--r8jwa9ayb3301a972ahi6c.biz/?p=302

Tech TIPS:Windowsで画面外に移動してしまったウィンドウを表示領域内に戻す - @IT
http://www.atmarkit.co.jp/ait/articles/0312/06/news006.html

しつこく雨が続きますね

いやんなっちゃいますね。

Java6 + Tomcat7.0.30 のプロダクトをJava8にバージョンアップして動かしてみたところ、JasperがJSPコンパイルできないぜ例外が発生してエラーになった。

org.apache.jasper.JasperException: Unable to compile class for JSP: 

An error occurred at line: 1 in the generated java file
The type java.util.Map$Entry cannot be resolved. It is indirectly referenced from required .class files

ビルドパスも再確認して問題なさそうだったので、ググってみたら色々と引っかかる引っかかる。

どうもJDK8未対応のTomcatバージョンではこれが起きて動作しないらしく。対応としては、まずTomcatのバージョンを上げる。次にJavaのバージョンを上げる、という感じなんでしょうな。

http://stackoverflow.com/questions/19243458/tomcat7-not-compiling-jsp-examples

https://bz.apache.org/bugzilla/show_bug.cgi?id=57445

今月はこんな感じのこと沢山やるので、トラブルシュートの毎日になりそうだ。

Spring in Summer ~ 夏なのにSpring に行ってきたメモ

最近出席したカンファレンスの中では、特に得る物がない残念な1日でしたが、折角メモ取ったので挙げておきます。知人に再開したのもあって、予定外にディナーパーティーまで参加してしまった。

http://www.springframework.jp/summer
https://jsug.doorkeeper.jp/events/27682

公式ハッシュタグ:#jsug_sis

日時:2015年 8月 28日 (金) 10:00 〜 18:30 (開場 9:00)

場所:〒100-6640
東京都千代田区丸の内1-9-2
グラントウキョウサウスタワー 23〜41階

Room 1 (41F 200名)
Room 2 (41F 100名)
Room 3 (23F 50名)

10:00 - 10:30 R1-1.オープニングセッション

 長谷川裕一 (日本Springユーザ会 会長)

10:30 - 11:30 R1-2.マイクロサービスアーキテクチャの設計

鈴木 雄介 (日本Javaユーザーグループ 会長)

http://www.slideshare.net/yusuke/jug2015

MSA(Micro Service Architechture)

  • MSAの2つの側面
    • 技術面:分散配置と統合
      • サービスをサービスで構成する
        • 静的要素の組み合わせから動的要素の組み合わせへ
      • メッセージによる統合
      • サービスをマネージする
        • 稼働監視、依存性管理、
    • 文化面:持続性と分権
      • サービス全体を持続的に動作させる
        • ソフトウェア開発からITサービス運営へ
      • ドメイン固有の技術と運営
        • ドメインごとの自主性を認め、標準化を否定する
      • ドメイン個別のライフサイクル
  • MSAの背景
    • ウェブサービスのレガシー化
      • いまやエンタープライズよりも巨大で複雑
      • サービスの各要素特性や変化速度が大きく異なるため、標準化が出来ない
    • サービス共有の一般化
      • サービスレベルがコードで管理できる
        • SDx流れ。様々な仮想化技術
        • サービス=非機能要件的なもの。性能や可用性など
        • コードが機能だけではなく、サービスを管理できる
      • 動作構成パターンの共有化
        • OSSは静的な構成の共有化を実現し、APIは動的な構成の共有化を実現した
  • MSAとは
    • 新しい理想論ではなく現実解
  • MSAを理解する
    • 技術論よりは技術管理論
      • いかに技術をマネジメントするかという方法論
    • 粒度ではなく関係性に注目を
  • システム統治としてのMSA
  • MSAの適用
    • MSAは銀の弾丸ではない
      • SOAは必ずしも悪ではない
    • とはいえ、関係性を重視するアプローチは重要
  • MSAと開発プロセス
  • MSAのデザイン
    • 前提:企業システムにおける適用
    • ドメインの発見
      • ドメイン=変化の境界線
        • 変化の境界線を見つける
          • モジュール化は変化の境界線によって起きる
        • 変化の要因を品質特性から理解する
        • 変化の濃淡に線を引く
    • プラットフォームの利用
      • プラットフォーム=共有の動的資産
        • 複数ドメインを許容するための基盤
        • 今後はプライベートPaaSやハイブリッドPaaSの登場が予想される
    • ドメインとプラットフォーム
      • バランスをいかに取るか
        • 独立させすぎると無駄が増える
        • 共有し過ぎると対応できない
  • MSAの実例
    • 企業システムで言えばECサイト
      • 既存の社会的責任が維持されてしまう
      • 多様な利害関係者/ルール/システム
      • レガシー連携と最新トレンドへの追随
      • 複雑系と柔軟性の課題が多い
    • ECサイトドメイン設計
        • 特性
          • 流入→商品検索→購買
            • それぞれでの複雑性や利用者数の違い
            • 買わせるための属性と売るための属性の違い
        • 個人情報やカード番号
        • 基幹(請求/在庫など)との連携
          • データの整合性と鮮度のコントロール
    • ECサイトの構成
  • Springについて
    • Spring Bootだけじゃない
      • あらゆる粒度で関係性の管理が行える
        • Framework:アプリ内の関係性管理
        • Integration:アプリ間の関係性管理
      • Springは何かを規定しないからこそ、アーキテクトにとって魅力的であり続ける
        • プラットフォームとしてのオープンさが魅力
  • 「MSAにする」のではなく「MSAになる」のが健全
    • MSAはITサービスを持続するためのアーキテクチャデザインコンセプト
    • 個別の技術に惑わされることなく「適切さ」を維持することを重視すべき

11:30 - 12:30 R1-3.大規模エンタープライズにおける、最新のフロントエンド・アーキテクチャへの挑戦

近藤 健 (株式会社野村総合研究所

ObjectWorks+という内製F/Wについて、
JavaEEに加えて、SpringMVC+AngularJSを2014から追加した、という話。

  • 背景と課題
    • モバイル化が一巡し、再びUI要件の上昇フェーズに入っている
    • Flexで開発されたアプリケーションのHTML5化の検討が始まっている
      • 2016年、IE11以外はサポートされなくなる →そういえばそうだ
    • 海外では金融系やBtoBシステムでもUXへの投資が始まっている
    • 大規模エンプラの制約
      • アプリ開発方式は変えられない
      • 組織の役割分担は変えられない
        • NRIの組織は、アプリと基盤で分かれているため、AOPで成果物を分けている
      • ミドルウェアは変えられない
        • ObjectWorks+として開発している(JavaEEベース)
    • JavaScript開発が当たり前に→JSFの弱点が顕在化
      • JSFはサーバサイドJavaでUIをコントロールするモデル
      • JSFの画面をJavaScriptで変更すると予期せぬ動作をする
  • サーバサイドアーキテクチャの最新化
    • 大規模エンプラの制約への対応
      • ま、フツーの話
    • SpringMVCに足りない機能の追加
      • 独自の例外ハンドリング
  • クライアントサイドアーキテクチャの最新化
    • クライアントサイドMVC導入
      • jQueryよりもAngularJSベースの標準化により、オフショア開発への切り出しがし易い
      • クライアントサイドMVCにより、クライアントサイドだけでモックアップの構築が可能、捨てずに使える
    • 導入リスクを下げるための試み
      • JavaScriptの欠点を補うためTypeScriptを採用する
        • データに型を持たせて、固く開発できる
      • AngularJS&TypeScriptにより、SpringMVCのアナロジーで説明し、学習コストを下げる

NRI社のフレームワークは、組織構造に縛られ、自社のビジネス構造に縛られ、自由度・柔軟性が少なくて窮屈そうに感じた。それでも競争力を維持しているというのは、それは「技術力」によるものではないんだろうと思慮。

12:30 - 13:30 昼休み

13:30 - 14:30 R1-5.キーノート The Macro of Microservices

Josh Long (Pivotal) 同時通訳あり

  • Agile Manifest
  • Dev Ops
  • Value Chain Map
    • Platform
  • writing cloud-native software
  • NETFLIX
    • Product team using microservices
      • Prod Mgr
      • UX
      • Dev
      • QA
      • DB Admin
    • Platform team (Producing API)
      • Sys Admin
      • Net Admin
      • SAN Admin
  • microservices enable bounded contexts
    • Martin faulers Blog...

14:30 - 15:30 R1-6.Spring DIと大規模プロジェクト、春は来るのか本当に?

三宅 泰裕(株式会社ワークスアプリケーションズ)

HUE(High Usability Enterprise)プロジェクトの中でのお話

  • プロジェクトの規模感
    • 初期:10人規模
    • 中期:50人規模
    • 後期:500人規模、グローバル混成部隊(今ココ)
  • 構成の変遷
    • 初期:Springでできるだけ構成
    • 現状:
      • RDBMS:Cassandra, Elasticsearch ...
      • Batch:SparkStream + SparkBatch
      • Cache:bugが見つかる...修正後、再度利用
      • Front:SPA, karma + jasmine ...
      • 結果:MVC / Cache / Test / Context
  • プロジェクトへの要求
  • @Autowired使いたいよね
    • @ComponentScanとセットで
    • でも、時間の経過とともに
      • AP起動時間が遅くなっていく
        • 瞬間的にスケールしたい!!
      • プロジェクト間の依存関係が
        • BeanCreationException...
      • 依存性の注入って言うけど
        • で、結局、何が読み込まれているの?
  • 先に結論!
  • Modularityを担保したい
    • ポリシー
      • 全部一個にしない
      • 開発者は必要な依存(Maven)を選ぶ
  • ComponentScan使いたい
    • @Autowiredが救世主?
  • 最低限の規約遵守
    • interfaceベースでのScan
    • テストしやすいように
  • 表面的に噴出した問題
    • 依存関係が謎、解決できない
      • 推移的依存解決
    • 起動時間が遅い
    • plug-in的に扱うものは?
    • 以下、詳細
    • 依存関係が謎、解決できない
      • 犯人は、実はComponentScan
        • 推移的依存関係の解決を行ってしまう
        • 見えない依存が勝手にできる
    • 起動時間が遅い
      • ComponentScan(対象PKG以下のフルスキャン)
      • Bean生成時の問題
        • コンストラクタでDB読み込み...してた
          • 起動時に寄せればいいってもんじゃない!
  • 人が増える=jarが増える
    • どんどん遅くなる
      • Eclipseだともっと遅い
      • 開発者のストレス → 遅いことに慣れてしまう
      • 小さく作れなくなる
  • 人が増える=知識も薄まる
    • 無駄を無駄と思わず、当たり前に感じる人が増える
  • plug-in的に扱うものは?
    • 依存が本当に分からないものもある
  • ソリューション
    • フレームワーク開発者
      • 速度を重視
        • Scanしない → @Component にあたるものは自前で管理
    • 業務開発者
      • 効率を重視
        • Scanする → DAO / Controller / Service
    • Scanしない
      • アノテーションベースDIからJavaベースDIへ
        • @Configurationを有効活用
        • @Beanも有効活用
        • applicationContext.xmlは使わない
      • メリット
        • 依存の整理が楽
        • テストも一元化
        • Grep天国との決別
    • ちゃんと@Importも使う
  • こうすると、実は問題が...
    • N回読み込まれる問題
      • @GuardedConfiguration(自作)
        • 2重登録の防止
  • 実装とインターフェイスの分離をConfigにも適用
  • テストも楽ちんに
    • @ContextConfigurationでもConfigクラスを読める
    • 嬉しいのは、ユニットテストのしやすさ

15:30 - 16:30 R1-7.The Bootiful Application

Josh Long (Pivotal) 同時通訳あり

github.com/joshlong/bootiful-microservices
twitter @starbuxman

start.spring.io/

make jar not war.

  • using spring-boot-starter-actuator / spring-boot-starter-remote-shell
    • actuator(下記のURLが自動で作られる)
      • /metrics
        • システム情報が照会できる
      • /trace
        • 直近100リクエストとレスポンスが見える
      • /env
        • JVMパラメータが参照できる
      • /info
        • プロダクトのバージョンなどの情報を埋め込んでおける
      • /mappings
        • アプリケーションのリクエストマッピングが一覧で見える
      • /beans
        • Beanオブジェクトのdependenciesが一覧で見える
      • /health
        • アプリケーションの状態(UPとかDOWN)が照会できる

16:30 - 17:30 R1-8. 【前半】 Spring Framework/Boot/Data徹底活用〜Sprnig Data Redis編〜【後半】 Spring適用のアンチパターンとベストプラクティス(仮)

Spring Data Redis
  • JedisのローレベルAPIを使うのではなく利用しやすいTemplateを提供している
  • RedisCaheManagerを利用することでspring-contextのCache機構と連携可
    • キャッシュとして戻り値を保持したいメソッドにCachableアノテーションを定義
    • Redisに存在しない場合のみ、メソッドの中身が呼び出される
    • 下のコードはSQL実行結果をキャッシュとしてRedisに乗せる例
  • spring-boot-starter-redis / autoconfigration を依存関係に加えるだけ
  • Redisの構成
    • Sentinel (Master Slave 投票でMasterを決定)
    • Load Balancer
  • JedisはRedis Clusterに対応しているが、Spring Data Redisが未対応
    • なので、現実的には、Sentinel or LB が選択肢
    • Read/Write先を区別したい場合は、Connectionまわりはカスタマイズが必要
Spring適用のアンチパターンとベストプラクティス

http://www.slideshare.net/Yoichi-KIKUCHI/jsug2015-summer-spring

  • オレオレフレームワークを作りまくった時代を振り返って
  • やっぱり素直にSpringに沿った作りにすべきだよねーという話
    • 何も得るものなし

17:30 - 18:30 R3-9.Spring Bootをフル活用した継続的デリバリーの実践

辻 昌佳 (株式会社 マネーパートナーズソリューションズ)

[対談:日本Springユーザ会 会長 長谷川裕一]

  • MPSシステムのサーバーサイドは全てSpringを採用
  • ドメインごとに5チーム(2〜10数名)
    • ポータル開発
    • 取引基幹系
    • 取引ツール
    • 社内
    • 共通開発
  • 課題
    • 小〜中規模プロダクトを多数抱えている
    • いかにして効率よくリリース、保守し続けていくか?
      • チーム専属の開発者アサインは非効率
      • アーキが異なると学習オーバーヘッドが大きい
      • 独自の構成があると担当が限られてしまい問題解決が遅れる
  • Springフレームワークを基盤とした共通開発手法を確立
  • 結果
    • チーム間で開発者を共有できるように
    • 保守、運用が容易にできるようになった
    • 統一感を持った見積りができるようになった
      • 見積りのブレが少なく
      • 見積りのチェックがしやすい
      • テンプレート化した見積りツールで簡単に見積もれる
  • フレームワーク
  • Springベースのフレームワークツールセットを活用して継続的デリバリを実現
  • 自動生成デモ(動画の再生と説明)
    • gitリポジトリから自動生成セットを取得し
    • ケルトンプロジェクトの初期化
    • ビルド・プロセスの起動
    • SwaggerからサーバのAPIを確認 ☆これは便利かも☆
    • 組み込みH2データベース上のデータを確認
    • プロセスの終了
  • デプロイ〜リリースデモ(動画の再生と説明)
    • 仮想マシン(Vagrant)にデプロイ
    • 仮想マシン上にリリース
    • プロセスの起動
    • SwaggerからサーバのAPIを確認
    • 組み込みH2データベース上のデータを確認
    • プロセスの終了
      • コマンドから、spring-boot内のActuatorを使って停止させている
  • これから
    • Springのライブラリ群の取り込み
      • SpringSecurity-OAuth
      • Cassandra
    • フレームワークを活用した共同開発
    • マイクロサービス開発への対応
  • MPSのこれから
    • ECや物流など他業種への展開
    • サービスの継続性を損なわない、システムの移行開発
    • 当社のノウハウを展開して、開発の効率化をサポート
  • JSUG会長の長谷川さんと対談
  • UI側はデフォルト実装は用意しているものの、技術の移り変わりが激しいので強制はしていない
  • 反面、WebAPIの構築は真剣にやる

19:00 - 20:30 41F 食堂: ディナーパーティー(無料)を開催。LT大会(飛び込み可)

携帯のメールアドレスに迷惑メールが来たので通報した

ついでに、通報の仕方をまとめておく。

元メール

差出人: admdm65z@i.softbank.jp
日時: 2015年7月1日 17:43:56 JST
宛先: (ワシの携帯メールアドレス)
件名: 久しぶり〜(≧.≦)

メアド変更するので
登録宜しく(//∇//)

これ、すごくよくあるパターンですな。なんだそのフザけた顔文字は。誰だお前は、名を名乗れ、と。
んで、各携帯キャリアなどの迷惑メール通報ガイドに従って、メールを転送しておきました。


迷惑メールを申告する | 迷惑メールでお困りのとき | お客さまサポート | モバイル | ソフトバンク
http://www.softbank.jp/mobile/support/antispam/report/

迷惑Eメールご申告方法 | スマートフォン・携帯電話に関するお問い合わせ | au
http://www.au.kddi.com/support/inquiry/mobile/mail/#anc_iphone


こんな宛先もあるみたい。


迷惑メール相談センター|情報提供のお願い|JADAC
http://www.dekyo.or.jp/soudan/ihan/


読者の皆様におかれましても、「あなた誰?」みたいな返信などのアクションは間違ってもしないように、上記のページを参考に粛々と迷惑メールを転送されることをお勧めします。