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ビューの中のBranchesLocalmasterを右クリックしてMerge…を選択します。

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

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

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

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

Enter image description here

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

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

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の日本語文字化けがひどいですね。近いうちに何とかします。

[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のサーバからリンク先に都度アクセスするので、最悪アクセス遮断されかねない
    キャッシュするべきですね。。。

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

ubuntu server 14.04にwp-cliを使ってコマンドだけでWordPressをインストールする

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

手順

1. Apache, PHP, MySQLをインストール

必要な物をapt-getでインストールします。

sudo apt-get install apache2 php5 libapache2-mod-php5 mysql-server php5-mysqlnd

php5libapache2-mod-php5の依存関係でインストールされる気がするけど気にしない。

2. wp-cliをインストール

コマンドラインでWordPressを操作するためにはwp-cliが必須です。

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

動作確認はphar wp-cli.phar --infoで。
毎回phar /path/to/wp-cli/wp-cli.pharと入力するのは面倒なので、実行権限を与えた上でパスが通っているディレクトリにwpという名前でコピーしておくと便利です。

3. データベースを用意

mysqlのデータベースを作っておきましょう。

mysql -u DBUSER -p
mysql> CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8;

必要に応じてWordPress用のMySQLユーザを作って権限を与えておきます。

4. wp-cliでWordPressをインストール

残りは一気に行きましょう。

mkdir -p /path/to/wordpress
cd /path/to/wordpress
wp core download --locale=ja
wp core config --dbname=wordpress --dbuser=USER --dbpass=PASSWD
wp core install --url=http://example.com/wordpress --title=TITLE --admin_user=ADMIN --admin_password=PASSWD --admin_email=admin@example.com

WordPress 4.1 “Dinah”がやってきた

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

WordPress 4.1 “Dinah”がリリースされました。
このバージョンからデフォルトテーマが”Twenty Fifteen”に変更されています。

なんていうか・・・

めっちゃシンプルですね。

WordPressユーザーにとってもう一つ大きな違いは、集中執筆モードの変更です。
これまでは集中執筆モードに切り替えるとエディタ以外のすべてが消え去ってしまい、ぶっちゃけかなり使いづらい物でした。
また、エディタのボタンも画面上部に離れてしまうので、書式設定には向いていません。

4.1の集中執筆モードは、エディタは残しつつ、エディタ以外のメニューなどは非表示となります。

非表示となった部分を使いたい場合は、カーソルを持って行くことで再び表示されます。
また、再度入力を再開すると、エディタ以外はまた非表示になります。

今までと違って状態を切り替えるのにマウスクリックが不要になったので、結構快適です。

Javaで(サーブレットコンテナ|EJBコンテナ|メッセージブローカー)を組み込む話

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

Javaに組み込めるミドルウェアを調べてみました。
それぞれ解説リンクを掲載していますので、参考にご覧ください。

サーブレットコンテナ

EJBコンテナ

メッセージブローカー

Javaだといろんなミドルウェアがあるのが”当たり前”みたいな感じがして、本格的な入門にもハードルが高いのが現状だと思います。
特にJavaEEになると、日本語の書籍がほぼ無いのもあって業務で使わない限りなかなか勉強する機会が無いですね・・・

「ぼくがかんがえたさいきょうのアプリケーションフレームワーク2014.12」※実装は無いよ!

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

前提

バックエンドはJavaで構築することが前提です。今Javaプログラマなので。

構成と妄想

クライアント <- JSON -> Web <- JMS -> AP <- JPA -> DB
  • それぞれのサーバはスケールアウト出来る物とします。
    そのためにはセッションはDBに格納する必要がありますね。
    今の段階ではXOOPS CubeのDBセッションみたいな管理方法をイメージしています。
  • あえて特定のプロダクトに依存しない書き方をしています。
    それぞれの実装は好きな物を組み合わせることが出来ます(EclipseLink or Hibernate, ActiveMQ or RabbitMQ, Tomcat or Jetty, …)。
    まあ、プロダクト間の差異を吸収するのはフレームワークの仕事ですしね。
  • 基本的にはAPIを通じてアプリケーションを利用することになります。
    そのため、クライアントがWebブラウザだろうがSwingアプリだろうがSWTアプリだろうが全く気にしません。
    ただし、Webサーバにプログラムと一緒にビューをデプロイするのはあまり好みではないです。
  • The Twelve-Factor Appの影響を大いに受けています。
    従ってWeb/APそれぞれのサーバに特別なミドルウェアはインストールしない想定です。
    Webは組み込みTomcatかJettyを使えば良いですし、ActiveMQならアプリケーションに埋め込めるのでメッセージブローカーをインストールする必要はありません。RabbitMQはどうなのかな?

まとめ

「なんていうか・・・すごく言葉にしづらいんだけど・・・・・・あんまりまとまっていませんね!
タイトルに「2014.12」って付けてしまったので、またそのうちやるかも。

HibernateのCriteiraをメソッドチェーンで書いたらなぜかテンションが上がった件

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

業務でHibernateを使っていますが、これまでは弊社内の大半の実装に合わせてこんな感じでCriteriaを書いていました。

Criteria criteria = session.createCriteria(Hogehoge.class);
criteria.add(Restrictions.eq("userCode", userCode));
criteria.add(Restrictions.in("fugaCode", fugaCodes);
criteria.add(Restrictions.ge("targetYearMonth", targetDate);
ProjectionList projectionList = Projections.projectionList();
projectionList.add(Projections.sum("days").as("days"));
projectionList.add(Projections.sum("hours").as("hours"));
criteria.setProjection(projectionList);
criteria.setResultTransformer(CriteriaSpecification.ALIAS_TO_ENTITY_MAP);

今日は実装中に仕様追加が発生したので、ストレス解消を兼ねてスピード重視で実装したら、いつの間にかメソッドチェーンで書いていました。

Criteria criteria = session.createCriteria(Fugafuga.class)
    .add(Restrictions.eq("userCode", userCode))
    .add(Restrictions.in("fugaCode",  fugaCodes))
    .add(Restrictions.ge("targetYearMonth", targetDate))
    .setProjections(Projections.projectionList()
        .add(Projections.sum("days").as("days"))
        .add(Projections.sum("hours").as("hours")))
    .setResultTransformer(CriteriaSpecification.ALIAS_TO_ENTITY_MAP);

流れるように実装できたので、自分にはメソッドチェーンの方が向いているようです。
弊社のコーディング規約に特に記載が無ければ、今後ともメソッドチェーンで書きたいですね。


Criteriaをメソッドチェーンで書くと、次のような利点があるように思います。
* (作るべきSQLが見えているなら)流れるように書き表すことが出来る
* わざわざcriteria(変数名)や;(セミコロン)を書かなくて良い
* ProjectionListを変数に格納しなくても良い
* Eclipse等のIDEで整形すれば、適度にインデントが設定されて見やすい

「俺ならこういう理由でこうしたい!」という話があれば、是非お聞かせください。