Zabbix アクションが発動しない時にチェックする項目

自分用メモ。徐々に追記していきます。

• アクションが発動しない(メールが飛ばない、など)

  • アイテム
    • 正しく取得できているか
      • 有効/無効
      • 実行間隔
      • 種別は正しいか(数値、文字列、ログ...)
  • トリガー
    • イベントが発生しているか
    • (ログの場合) ステータスが正常状態か or 「障害イベントを連続して生成」にチェックがついているか
  • アクションの条件
    • 有効/無効
    • トリガー(深刻度)
    • アイテム(アプリケーション)
  • ユーザ
    • メディア(深刻度)
    • ユーザグループ
      • 有効/無効
      • 権限
        • ホストグループ
        • テンプレートグループ

これらの掛け合わせなので、どれかが間違ってるとアクションは発動しません。

Zabbix難しいよ、って言う人はこの辺の理解でつまづいているように見えます。

理解できてもなかなかサクッと発動してくれなかったりするんですよね。何かいいテスト・デバッグ方法はないものでしょうか。

Bootstrapのbtnとdisabled

BootstrapのCSSを適用するとbutton以外のタグでもボタン化することが可能です。 さらにdisabledなどの状態も含めたCSSがセットになっているのでデザインにこだわらないWebアプリを開発する際には非常に重宝します。

これにAngularJSのng-clickやng-disabledなどを組み合わせることでお手軽にUIパーツが組めるのですが、どのタグにボタンを適用するかをその場のフィーリングで決めていたら軽く痛い目に遭いました。

具体的にはAタグをボタン化していたものについて、ng-disabledが効かずクリックできてしまうというものです。

ng-disabledが効かないというのは半分間違っていて、見た目上はdisabledなのですがクリック出来る状態で、見ただけじゃ気付かない罠でした。(マウスオーバーでカーソルも禁止マークになります)

サンプル http://plnkr.co/edit/sDYTmQFBUdc9VcxSw0BZ?p=preview

class="btn"はdivやspanでも使えますが、やっぱりクリックが発動します。

BeanValidatorをJava8 Streamで書く

コードレビューしてて思ったのが、BeanValidatorの処理ってJava8ならもうちょっとスマートに書けるのではないか、ということ。

どうせみんなコピペしてるんでしょ？と思ったので書いてみました。

ちょこっとスッキリしました。

後で自分がコピペして使う用として残しておきます。

どうせこの形で使うことがほとんどでしょうから、staticなメソッドになっててもいいような…。

AngularJS & Jerseyでファイルアップロード&JSONでパラメータ連携

Jerseyでのファイルアップロードって、よく見かけるサンプルではファイルもパラメータもmultipart/form-dataで一緒くたにされてしまいますが、実際にはパラメータ内に配列やオブジェクトが含まれていることが多いので、やっぱりいつも通りJSON経由で一撃でバインドしたいですよね。

今年買ったガジェット振り返り

昔からガジェット好きを公言してる割には、ここ数年はあんまり変なものは買わなくなった気がします。

以前は様々な機器を駆使して目的を達成させていましたが、最近はスマートフォンやタブレットでほぼ要件が満たせてしまっていて、便利になったのはいいですが趣味としては寂しい思いもあります。 さらに、最近の機器の性能的な寿命が延びていることもあって、結構長く使いそうなものばかりです。

去年くらいから、会社以外の外で何かする機械も多くなってきていて、それに合わせて買ったものもモバイル関連ばかりになってます。

mavenデプロイで軽くハマった件

初期開発ベンダーの秘伝のタレのようなbuild.xmlから脱却して、コモディティ化されたビルド・依存性管理とビルド成果物の管理をきちんとやらなきゃダメ、ってアジし続けて最近になってようやく許しが出たのでSonatype Nexusをセットアップして既存プロジェクトとにらめっこしながらpom.xmlと格闘の日々。

JenkinsのプラグインとNexusがよく出来過ぎててMavenインハウスリポジトリの構築やデプロイ設定そのものはすごく簡単。

問題はpom.xml。

「依存ライブラリのバージョンは移行前と完全一致」「ソースコードのantビルド結果とmavenビルド結果はバイナリ完全一致」といった多分そこまで頑張らなくてもいいんだろうけど、何かあったら絶対ツッ込まれるポイントはどうにかクリア。

Snapshotのビルドとデプロイまで上手くいったので次はRelease、と思ったら以下のエラーでハマる。

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on project XXXXXX: Cannot prepare the release because you have local modifications :
[ERROR] [target/XXXXXX-0.0.1-SNAPSHOT.jar:unknown]
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on project XXXXXX: Cannot prepare the release because you have local modifications : 
[target/XXXXXX-0.0.1-SNAPSHOT.jar:unknown]

    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
    at org.jvnet.hudson.maven3.launcher.Maven32Launcher.main(Maven32Launcher.java:132)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:238)
    at jenkins.maven3.agent.Maven32Main.launch(Maven32Main.java:181)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at hudson.maven.Maven3Builder.call(Maven3Builder.java:136)
    at hudson.maven.Maven3Builder.call(Maven3Builder.java:71)
    at hudson.remoting.UserRequest.perform(UserRequest.java:121)
    at hudson.remoting.UserRequest.perform(UserRequest.java:49)
    at hudson.remoting.Request$2.run(Request.java:326)
    at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.maven.plugin.MojoFailureException: Cannot prepare the release because you have local modifications : 
[target/XXXXXX-0.0.1-SNAPSHOT.jar:unknown]

    at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:299)
    at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:247)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
    ... 31 more
Caused by: org.apache.maven.shared.release.ReleaseFailureException: Cannot prepare the release because you have local modifications : 
[target/XXXXXX-0.0.1-SNAPSHOT.jar:unknown]

    at org.apache.maven.shared.release.phase.ScmCheckModificationsPhase.execute(ScmCheckModificationsPhase.java:185)
    at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:234)
    at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:169)
    at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:146)
    at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:107)
    at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:291)
    ... 34 more

なんかもう全然わからなくて泣きそうだったんですが、どうやらtargetディレクトリをリポジトリに書いちゃっていたのがまずかったようです。(target/**はignoreしてるけど、target自体は登録されていた)

とりあえずはワークフローを一本通せたのでひと段落。

あと、ときどきデプロイ時に

WARNING: Couldn't clean up oid=3 from null

というのが出るんですが、情報が見当たらず。デプロイ自体は問題なくうまくいっているので放置ですかね...

今まで「Mavenは依存性解決とビルドのためのツール」という感じしか持っていませんでしたが(SNAPSHOTの意味すらよくわかってなかった)、この件でいまさらながらMavenのことがそこそこわかってきたような気がします。

Seasar2使いがこの先生きのこるには

(手前ツイートですが)

ひが氏「Seasar2から卒業して欲しい＆Seasar2サポートは2016.9.26で打ち切る 」#seasarcon

— ちょなそ (@chonaso) 2015, 9月 26

当初、色んな考え方を書こうと箇条書きにしてみたらかなり発散しちゃったので、あの場で自分が思ったことだけ書きます。*1

*1:※この発言は個人の見解です。所属する組織の公式見解だったらいいのに。