[Eclipse][EGit] .projectがルートに配置されるようにGit管理する

前提: Gitのuser.name, user.emailが適切に設定されていること。

この記事の手順で作成したリポジトリは https://github.com/maruTA-bis5/git-init-eclipse です。

1. EclipseのProject Explorerより、Git管理したいプロジェクトを右クリックし、Team > Share Project…を選択する。

2. Share ProjectダイアログのUse or create repository in parent folder of projectを選択する。

3. 対象のプロジェクトを選択し、Create Repositoryボタンをクリックする。

4. Finishをクリックする。

ここまででローカルリポジトリが作成されます。次は初回のコミットを行います。

5. Git Stagingビューを開く。

6. Unstaged ChangesのファイルをStaged Changesに移動し、Commit Messageを入力してCommitをクリックする。
このとき、*.classファイルは表示されていませんが、*.classファイルが出力されるディレクトリは.gitignoreに記載されているため無視されます。他にも無視するファイルがあれば.gitignoreに追記しておきます。
※.gigignoreはProject Explorerには表示されないので、このタイミングで修正するか、Git Repositoriesビューから開く必要があります。

初回コミットが完了したら、リモートリポジトリにpushします。(リモートリポジトリでの管理が不要ならここまで)

7. Git StagingビューのPush HEADボタンをクリックする。

8. Location > URIにリモートリポジトリのURL、認証が必要ならAuthenticationを入力しPreview >をクリックする。
画像ではSSHを使用する形で入力していますが、HTTP(S)でも問題ありません。
パスワード認証が必要な場合は、Authenticationを入力しておきます。

9. ブランチの指定は基本的に変更しなくて良いはず。前のステップで入力した認証情報に誤りがあればこの段階でエラーが表示されるので、一度戻って修正する。問題なければPreview >をクリックする。

10. pushのプレビューを確認してPushをクリックする。

11. pushが完了するとpush結果が表示される。失敗した場合もこのダイアログが表示されるので、必ずMessage Detailsの内容を確認する。

Mattermost Apps Framework をJava (JAX-RS)で試してみた

Mattermostと他のアプリケーションを連携する新しい方法として、Mattermost Apps FrameworkがDevelopers Previewとして利用可能になりました。

https://developers.mattermost.com/integrate/apps/

Appsの説明としてBe written in any language.と説明されており、せっかくなのでJavaで試してみました。普段仕事で使うのはJavaなので。。。

リポジトリ: https://github.com/maruTA-bis5/mattermost-apps-example-java

Appsを作るのに最低限必要なことはkaakaaさんの記事やQuick startを読んで頂くとして、それ以外に/installがOKのレスポンスを返さないとインストールに失敗するようです(画面上や/apps listでは問題ないように見えるが、Failed to install appのログが出力される)。mattermost-plugin-appsのコミット0cae0b3fadb7bfae03ffc015cab28654e4bf2d31で確認しました。

Java App側はJAX-RSでサクッと。Quick startではいくつかのjsonファイルを作成してそれをGo側で読み込んで返却するようにしていましたが、動的に生成できるようにデータモデルとJacksonを使っています。

内容としてはQuick startと同じなので代わり映えはありませんが、Goでなくても同じ挙動のAppsを作れるということは確認できました。より複雑な処理が必要になってくるとApps APIを利用することになりますが、Apps Pluginが提供するREST APIなのでそこまで難しくはなさそうです。

Pluginと違って、Go以外の言語でも簡単に作れるのは良いですね。

Jakarta Server Facesでも(MicroProfile) OpenTracingを使いたい

普段の業務ではモノリシックなアプリを扱っているので"分散"という点はあまり気にしていないのですが、やはり1リクエストでどの辺の処理に時間がかかっているのかを知りたい気持ちがあります。Jakarta EEとの統合を考えるとMicroProfile OpenTracingが第一候補になるかと思います。MP OpenTracingは主にJAX-RSとの統合を意識して作られていると思っていますが、Jakarta Server Facesとの統合を考えるといくつか検討すべき事項があります。

Jakarta Server Facesにおいてリクエストは"ライフサイクル"に従って処理される。ライフサイクル中の各フェーズにおける処理時間を把握できるようにしたい
- ライフサイクルについてはjsf ライフサイクルで検索してください
- Render Response Phaseで時間がかかっているのなら(カスタム)コンポーネントの処理を軽量化できないか検討するとか
- Invoke Application Phaseで時間がかかっているならビジネスロジックの最適化とか
- etc…
MP OpenTracingは@Tracedアノテーションを付与したクラス・メソッドの処理時間等を記録する(CDIのInterceptorで実現している)が、@ViewScopedなバッキングビーン(Serializableとする必要がある)で使用すると例外が発生する(メモるの忘れた・・・non-serializableなinterceptorは適用できないとかなんとか)

この2点を解決できれば有用かと思ったので、休暇を利用してさっと作りました。ライセンスはApache License, Version 2.0で、Maven Centralにも公開済みです。

https://github.com/maruTA-bis5/opentracing-faces

使い方はREADMEにも書いてあるとおりですが、基本的にMP OpenTracingと同じように使います。

Serializableでないバッキングビーンや、それ以外のCDI管理Beanなどについては、MP OpenTracingの@Tracedを使用します。
@ViewScopedなバッキングビーンに@Tracedを使うと怒られるので、@TracedSerializableを代わりに使用します。
各フェーズの時間を記録する場合、TracingPhaseListenerを使用します。

ちなみに動作確認はWildFly 20.0.1.Finalで行いました。他のアプリケーションサーバーでうまく動かなければ教えてもらえると助かります。

[Eclipse] [EGit] マージ時のConflict(競合)を解決する方法

この記事はStackOverflowの質問”How to resolve conflicts in EGit”に対する回答(https://stackoverflow.com/a/27914508)の日本語訳です。(2020/07/02 9:31閲覧 original: dan carter, edited: Peter Mortensen)
原文と同じく、CC BY-SA 4.0でライセンスされます。

Team Synchronize(チーム同期化)ビューを使っていますか?それは問題です。EGitの場合、競合の解決にTeam Synchronizeビューは全く使えません。代わりにGit Repository(Gitリポジトリー)ビューを使う必要があります。

Gitパースペクティブを開いて下さい。Git Repositoryビューの中のBranches→Local→masterを右クリックしてMerge…を選択します。

Remote Trackingには自動的にorigin/masterが選択されるはずです。Mergeをクリックして下さい。(訳注: 作業ブランチにmasterの変更を取り込む場合は、origin/masterを自分で選択する)

(訳注: 競合している場合は)result:conflictと表示されるはずです。

競合しているファイルを開くと、古いsk000l >>>> ==== <<<<スタイルで競合箇所が示されます。ファイルを編集して競合を解決し、保存します。

‘Git Staging'(Gitステージング)ビューを開くと、変更した(訳注: 競合していた)ファイルが’Unstaged Changes'(ステージされていない変更)に表示されます。右クリックして’Add to Index‘を選択してください。

これをファイルごとに繰り返します。

そして’Git Staging’ビューからコミットしてプッシュします。Git/Eclipseはあなたがリモートリポジトリに加えられていた変更をあなたのローカルのmasterにマージしたことを認識し、non-fast-forwardエラーは回避されます。

[Java] 2017/03/21 JJUG ナイト・セミナー参加メモ #jjug

2017/03/21に開催されたJJUG ナイト・セミナー「Enterprise Java最新動向〜Java EE 8とMicroprofile〜」に参加した際のメモ書きです。
気が向いたら内容を整理するかも。

Java EE 8の最新状況について

Java EE 8は仕様はFIXしていないので注意

GlassFish5

Promoted Buildがリリースされた3/13
- Java EE 8 CTS実施済み
- Nightlyは限定したテストケースのみ

Schedule

Final: 2017/07

Spec Status

大体は、Public Draftが出ている
MVC 1.0はdropされているのは周知の通り(コミュニティに移管)

各Specについて

JAX-RS 2.1

Reactive Client API
Server-Sent Events
Non-blocking I/O

歴史

1.1: クライアントAPIが未定義のため、各JAX-RS実装の独自API、Apache HttpClient等が使われた
2.0
- クライアントAPI追加
- RESTリソース(WebTarget)の生成が可能に
- 非同期呼び出し(.async()をコールするだけ、コールバックオブジェクト(InvocationCallback)の登録も可能)
- リアクティブプログラミング的な実装をする場合、InvocationCallbackがネストしてかなり気持ち悪い(callback hell)

2.1

SyncInvoker, AsyncInvoker(.async())に加えて、RxInvoker(.rx())が追加された。戻り値はCompletionStage

CompletionStage<Number> price = client.target(...);
CompletionStage<String> wheather = client.target(...);

price.thenCombine(wheather, (price, wheather) -> reserveIfAffordable(price, wheather));
// ^ priceの結果とwheatherの結果を受けて次の処理を行う。chain
// ^ TODO 後で調べる: CompletableFuture

Reactive API Pluggability
- 3rd party Reactiv Frameworkを利用できる
- RxJavaの場合、RxFlowable<Response> flowable = client.target(...).request().rx(RxFlowableInvoker.class).get();
  - .rx()の引数に、RxInvoker継承クラスを指定する

Server-Sent Events(SSE)

Jersey 2.8では先行して実装
サーバーからクライアントへの一方向通信のチャンネル確率
event, data, id, retry, comment
モダンブラウザサポート
WebSocketは専用のプロトコル(ws://)だが、Server-Sent EventsはHTTPベース
SseEvent, OutboundSseEvent(サーバサイド), InboundSseEvent(クライアントサイド)
- SseEventSync(サーバサイド), SseEventSource(クライアントサイド)
- 2017/02 SSE周りの仕様は変更されているので、最新の情報に注意(Jersey独自実装部分が変わっている

JSON-P 1.1

RFC 7159に対応(1.0はRFC 4627)
- トップレベルにおける要素がObject,Arrayしか無かったが、RFC 7159では全部置ける
JSON Pointer
- JSON中の特定の値を参照するための文字列の構文
- /0/user/address
- JsonPointer, JsonPointer#getValue
JSON Patch
- JSONを部分的に変更するような演算
- add/remove/replace/move/copy/test
- パッチ自体もJSONで記述される
- op(操作)とpathと(必要なら)値を指定するJSONで記述されたパッチを、別のJSONドキュメントに適用する
JSON Merge Patch
- RFC 7386
- Key-Value形式のパッチを渡すと、ReplaceなりAddなりをしてくれる(同一のキーがあればreplace, 無ければadd, Valueがnullならremove)
Patch Diff
- JsonPatch#diff, JsonMergePatch#diff`
Stream API対応: JsonCollectors

JSON-B 1.0

XMLに対するJAX-Bに似たAPI
ClassとJSONのマッピング、マッピングのカスタマイズ
デフォルトであればAnnotation/Configは不要
@JsonbFooBarアノテーションで、カスタマイズ可能
- Keyを変える
- Nullを出す/出さない
- 日付/数値のフォーマット
- etc…
JAX-Bと同様に、Adaptersも使える
- アノテーション使いたくなければこっち

Servlet 4.0

HTTP/2 サポート
- Request/Response Multiplexing(ストリーム多重化)
- Server Push
- Upgrade From HTTP 1.1 (HTTP Upgrade)
  - ALPNはJava 9で対応予定
Server Push
- PushBuilder

JSF 2.3

CDI統合
- Legacy Managed Beansは非推奨に
- CDIのManaged Bean対応
- より多くのJSF成果物へのInject

CDI 2.0

Java EEコンテナの外部でCDI動作定義(Java SE上で動く)
^ のために仕様の分割
- Core, for Java Se, for Java EE
非同期イベント
- Producer側で.fireAsyncをたたく、Observer側は@ObserveAsync

Bean Validation 2.0

Java SE 8サポート
- Date/Time APi
- Optional
- アノテーションの繰り返し
  - 従来はコレクションを使っていたが、同じアノテーションを併記できる(Java SE 8による
- コレクション要素への制約適用
  - 型パラメータに対してアノテーションをつける
組み込みアノテーションの追加
- @NotEmpty
- @NotBlank

Security API for Java EE

セキュリティ周りの標準化
Authentication Mechanism
- アプリケーションがアクセス可能な認証機構
- 従来: 各APサーバや3rd partyの実装を用いる
Identity Store
- アプリケーションがアクセス可能なアイデンティティストアの標準化
Security Context
- プラットフォーム・スコープのセキュリティ・コンテキストの標準化

wrap-up

今まで欠けていた部分を補い、Java EE 9に向けてポータビリティの強化が図られている
- Cloud Platformを見据えた対応

MicroProfile 背景と意義、そしてこれから

@kkzr https://www.slideshare.net/kenjikazumura/
MicroProfile.io
- 複数ベンダーによるEnterprise Javaのアーキテクチャ
- ゴールはStandardization

Java EEではだめなのか

マイクロサービスアーキテクチャ(MSA)

疎結合なサービスの集合体
意思決定とビジネスの速さを実現するための”手段”
- フィードバックループ(いわゆるOODAループ)による進化

MSAレイヤーと構成技術

アプリケーション
- サービス分割、ステートレス、API
アプリケーションサーバー
- REST, 非同期, memory footprint
- MicroProfileはこの辺
VM/コンテナ
- docker, IaaS, サーバレス

Java EEのProfile

Full Profile / Web Profile
Java EEにProfileを追加できるのはOracleだけなので、ここにMicro Profileを追加するのはOracleの判断が必要

Java EEの状況

J2EE 1.2 ~ Java EE 7まで、リリースの間隔はだんだん延びている
Public Review から Final Releaseまで、結構時間がかかるが、Java EE 8はまだPublic Reviewに到達していない
2016/03の段階で、主な仕様はEarly Draft Reviewか、そこに到達していない状態
GlassFishのissuesは、V4以降はcreated/resolvedは少なくなっている
- マイクロサービス、クラウドの進歩は早いが、このGlassFishの開発状況でついて行けるのか?
- “Java EEが悪い”のではなく、”JCPのプロセスが悪い”かもしれない(アジャイル的ではない

仕様が先か、実装が先か

仕様を先に決めるアプローチ(JCPのアプローチ)
- Pros: 公正な議論、複数実装による適切な競争(よーいドンで実装着手できる
- Cons: 仕様策定に時間がかかる
実装を先に作るアプローチ(Linux Kernel等のアプローチ
- Pros: イノベーション向き(変化が早い
- Cons: 誰がどこで仕様を決めるか不明

JCP vs OpenJDK

JDKの側面
- Java SEのRI
  - JCP, JSRによる開発
- JDKのOSS
  - openjdk.java.net, JEPによる開発
- JCPから見ると、JSRで決まっていないJEPの仕様が(なし崩し的に)JSRになってしまう > 議論されない
MicroProfile
- MicroProfileの仕様が(最終的に)Java EEの仕様になる(といいなぁ
- OpenJDKに基づいて別のJava SE実装を作るのは難しく、競争が起きにくい
- MicroProfileははじめから競争を起こす前提(マルチベンダによる開発)

MicroProfile #とは

2016.06に設立
- RedHat, IBM, Payara, LJC, SOUJava等
2016.09 JavaOne でVersion1.0リリース
2017.01 富士通が参加
2017 2Q Ver1.1(plan)
2017 3Q Ver1.2(plan)
APSベンダーがMicroProfileを提供 > 市場が評価 > [OK]JCPへ提案, [NG]フィードバックを反映
アジャイル的にOODAループを実践して、最終的にJCPへ提案する

MicroProfile 1.1

1.0は、JAX-RS、CDI、JSON-P
1.1は、2017/2Qリリース予定
- Configuration API
- Health Check API
- JWT Token Definition
- Fault Tolerance
  - stretch goal: できなければ次のリリースで

Configuration API

設定の外だし
- 別環境への移動など、設定変更でリビルドを不要にする
設定の動的反映
- Netflix/archaiusの考え方
- 環境変更のたびにリデプロイを不要に
  - 接続先URLの変更など(DBが死んだから切り替える、とか)
優先度付けされた複数の設定(ConfigSource)で構成
1. システムプロパティ
2. 環境変数
3. 設定ファイル(META-INF/microprofile-config.properties)
Apache DeltaSpike由来のAPI
- メソッドベース
- アノテーションベース
  - @Inject @ConfigProperty ConfigValue<Integer>

Interoperable JWT RBAC

OpenID ConnectベースのRole Based Access Control
認証/認可
まだ具体的な仕様は少ない
- JSONのフォーマットはあるがAPIがまだ進んでいない
- Priority高いはずだが・・・

Service Healthchecks

アプリケーションのヘルスチェックをするRESTエンドポイント仕様
Kubernetes health check互換
チェック対象のアプリケーション(Producer)で、Health Check Procedureを定義(複数可)
- すべてのProcedureがUpならUpを返す
GET /health > 200 Up or 503 Down
- Procedureの結果をJSONでまとめて返す
(たとえば)JAX-RSのリソースで、@Healthをつけて、HealthStatusを返す

Fault Tolerance

アプリケーションの実行論理と、実行時のエラーハンドリングの分離
RetryPolicy, Fallback, CircuitBreaker, BulkHead, Timeout
- RetryPolicy: 条件(.retryOn)、間隔(.withDelay)、回数(.withMaxRetries)を指定
- Fallback: RetryPolicyを指定して、リトライに失敗した際の処理(.withFallback)を指定する
- CircuitBreaker: NetflixのHystrixインスパイア
  - closed: 正常稼働
    - 何度か失敗すると(10回中3回など)、open状態に遷移
  - open: リクエスト送信遮断
    - 一定時間後に(1分など)、half-open状態に遷移
  - half-open: リクエスト送信を再開
    - 指定回数成功したら(5回など)、closed状態に遷移
    - 指定回数失敗したら(5回など)、open状態に遷移
  - メソッドAPI、アノテーションAPI

BulkHead

処理毎に個別のスレッドプールを使用することで、異常時の影響を極小化したい

Timeout

リクエスト先がハングした時など、タイムアウトを指定しておく

サマリー

MicroProfileは、フィードバックループによるマイクロサービスのオープンなイノベーションを実践
実装(ベンダー)を選択可能
- アプリケーションのポータビリティを担保
最終的にはJCPで標準化を目指す
- 既存のJavaコミュニティを分裂させるものではない
- Javaの特徴の1つである”互換性”は損なわない

質疑

実装は早くても、Java EE 8とMicroProfileが両方存在する状態(HTTP/2とSPDYのような)になり、きれいなループが実現できないのでは?
- 確かに、MicroProfileの方向とJava EEの方向が違ってくる可能性はある。しかしMicroProfileのメンバーはJCPにも参画しているので、方向性を合わせるような動きがあるのではないか。
  ※危惧としては、確かにあるので、努力していく

無理だと思ってたら結局毎日書けたのでAdvent Calendar振り返り

※この記事は丸太式 Advent Calendarの25日目です

まさか最後まで書けるとは思っていなかった

25日目です。

仕事で帰りが23時になる日も多かったですが、自分でもよく書けたと思っています。
~~何日か日付またいだけど~~

Advent Calendarの記事はAdventarにまとめてあります。
http://www.adventar.org/calendars/402

おおむね技術系の記事になっています。そういう仕事だし仕方ないね。
どうせ記事を書くなら業務からネタを持ってきたかったのですが、自社フレームワークだったりバージョンが若干古かったりしたので、あまり書くことがありませんでした。

毎日アウトプットするのは大変でしたが、来年は隔週くらいで何かしら出力していきたいです。

さて、明日は仕事納めです。
仕事納まるかなぁ・・・

皆さん、良いお年を！

GitHub Flowについて調べています

※この記事は丸太式 Advent Calendarの24日目です

GitHub Flowを弊社の開発で取り入れられないか検討するために、少し調べています。
#何も決定権は持っていないけど
とりあえず読んだ/読んでいる/読もうと思っているページを幾つかピックアップしています。
GitHub Flow（というかGit）を使った開発経験が無いエンジニアをうまく説得できる材料がそろえば良いと思っています。

https://gist.github.com/Gab-km/3705015
http://qiita.com/tbpgr/items/4ff76ef35c4ff0ec8314
https://pepabo.github.io/docs/github/workflow.html
http://komaken.me/blog/2013/09/09/git-flow%E3%81%A8github-flow%E3%81%96%E3%81%A3%E3%81%8F%E3%82%8A%E3%81%BE%E3%81%A8%E3%82%81/

GitHub Flowじゃないけど
http://www.slideshare.net/KatokichiSoft/git-flow-16616440

弊社の製品品質について若干問題が生じているので、社内でもっと活発に議論できればと思っています。

# 関係ないですがlink-cardの日本語文字化けがひどいですね。近いうちに何とかします。

Vimユーザー(見習い)のためのSoftware Design 2015年1月号

※この記事は丸太式 Advent Calendarの23日目です

こんばんは。Vim初心者です。
普段からできるだけVimを使おうと思っているのですが、会社のPCがWindowsなのでどうし
ても他のエディタを多用してしまいます。
ただ、そちらのエディタはMarkdownの構文強調に対応していないので、仕事の合間にメモ
を取る場合等、プレーンテキストのモードでMarkdownを書いたりしています。
また、この記事もMemolistプラグインで作成したMarkdownをほぼそのまま貼り付けていま
す。

Software Design誌の2015年1月号に、【「Vim使い」事始め】という特集が組まれています。
別に中の人でも何でもありませんが、Vimを使う上で必要なことが凝縮されているように感じました。

Software Design (ソフトウェアデザイン) 2015年 01月号 [雑誌]

本編はもちろん、@jnchitoさんと@kaoriyaさんのコラムは興味深い物があります。
これからVimを使おうとしている方はもちろん、Vimを使い始めてまだ間もない(私のような)方も是非読んでみてください。

私の.vimrcはGitHubで管理していますが、「ここはこうした方がいいんじゃない？」「こ
のプラグインはおすすめ」というご意見があれば、是非ご教授ください。
https://github.com/bis5/dotfiles

[WordPress]リンク先の情報をカード上で表示するlink-cardプラグインの今後

※この記事は丸太式 Advent Calendarの22日目です

昨日の記事で紹介したWordPressのプラグイン「link-card」ですが、現状あまり使いやすい状態では無いと思っているので継続的に開発していきたいと考えています。

現状の問題点

昨日の記事にも書きましたが、今のlink-cardプラグインには幾つか問題があります。
* キャッシュ機構がないので、アクセスのたびリンク先から情報を取得している
* aタグの直前に挿入するので、文の途中にaタグを使うと意図しないレイアウトになるかも
* etc…

今GitHubのIssueに登録してあるバグや機能拡張は今年度中にやると思います。
また、使いやすい形に出来るように自分でも使いながら考えてみようと思っています。

今後について

あまり英語は得意ではないので、しばらくはWordPress公式のプラグインディレクトリには掲載しないと思います。
将来的にプラグインディレクトリに公開することは十分考えられると思いますし、やる気はあります。

これからlink-cardをよろしくお願いします。

リンク先の情報を表示するlink-cardプラグイン[自作WordPressプラグイン]

※この記事は丸太式 Advent Calendarの21日目です

今日はWordPressプラグインを作りましたのでご紹介します。

link-cardプラグイン

基本情報

名前
link-card
概要
aタグにcreateCardクラス属性を付加しておくと、aタグの直前にカード状の情報ボックスを表示します。
動作確認バージョン
WordPress 4.1で動作確認しています。

使い方

プラグインをインストール

今のところ、GitHubでのみ配布しています。
https://github.com/bis5/link-card
「Download Zip」からZipをダウンロードして、wp-content/plugins/link-cardとして配置してください。
※GitHubからダウンロードしたZipファイルを展開すると「link-card-master」というディレクトリになりますが、「-master」は除いてください。

記事を作るとき

リンクを作成するとき、以下のようにclass属性を追加します。

<a class="createCard" href="http://www.yahoo.co.jp">やふー！</a>

すると、記事を表示した際に、リンクのすぐ上にリンク先の情報が表示されます。
こんな感じです。
この時表示されるのは、titleタグの内容とmetaタグのdescriptionの内容です。

既知のバグ

リンク先のdescriptionに日本語が含まれると文字化けする
文字化けする例
descriptionを設定していないサイトではタイトルしか表示されない
代わりにog:descriptionとか使うと多分いい感じ
(バグと言うより仕様ですが)WordPressのサーバからリンク先に都度アクセスするので、最悪アクセス遮断されかねない
キャッシュするべきですね。。。

久しぶりにちゃんと成果が出た週末で、自分としては満足です。
もちろんこれから先も改修を続けるつもりなので、フィードバックやプルリクお待ちしています。

共有:

共有:

共有:

共有: