8月某日、私のブログ記事を紹介したいとの連絡が来た。
6年もブログ書いているとこんなこともあるもんなんだなーと、ちょっと嬉しくなりましたね。
で、紹介記事が公開されたのでご紹介。
紹介している記事はこちらで、
紹介された記事はこっち、
それかーって思いました。(Jenkins とか Cppcheck とか Visual Studio とか紹介してくれてもいいのよw)
なんか適当に書いた記事なので、こんなん紹介してもらっていいのかな?って気がしますが…
まぁいっかー
では、また来週。
2016年9月2日金曜日
2016年8月30日火曜日
このブログのアドセンス収益が最小支払額に到達しました
このブログを始めて約6年で、アドセンスの最小支払額に到達しました。
お小遣い稼ぎ程度に設定をしておりましたが、ようやくリターンが得られました。長かったですね。
こういったので生活している人は大変だなぁと思った。
さて、せっかくなのでここに至るまでのレポートを載せておこうと思います。

赤色がページビューで、青色が収益です。
ページビューは右肩上がり、収益は(先月が異常に高かったですが)、年を追うごとに少しずつですが上がってる感じでした。
さらに、直近一年間の月平均
月平均約300円の収益なので、1年で3600円。3年くらいしたら、また最小支払額に到達する感じですね。
収益を上げることがこのブログの目的ではありませんが、モチベーションの1つとして今後もやっていきたいと思います。どうぞ今後ともよろしくお願いします。
お小遣い稼ぎ程度に設定をしておりましたが、ようやくリターンが得られました。長かったですね。
こういったので生活している人は大変だなぁと思った。
さて、せっかくなのでここに至るまでのレポートを載せておこうと思います。
赤色がページビューで、青色が収益です。
ページビューは右肩上がり、収益は(先月が異常に高かったですが)、年を追うごとに少しずつですが上がってる感じでした。
さらに、直近一年間の月平均
| ページビュー | 表示回数 | クリック数 | 収益 |
|---|---|---|---|
| 9,318 | 17,980 | 4 | ¥309 |
月平均約300円の収益なので、1年で3600円。3年くらいしたら、また最小支払額に到達する感じですね。
収益を上げることがこのブログの目的ではありませんが、モチベーションの1つとして今後もやっていきたいと思います。どうぞ今後ともよろしくお願いします。
2016年8月22日月曜日
[Jenkins] Warnings Plugin の新規警告の計算について
Warnings Plugin には警告の総数もしくは新規警告数に応じて、ステータスを変更する機能があります。

この機能を使って、警告が残っていたら不安定(黄)にすることが多いのですが、
最近になって、警告が増えたら(新規警告があったら)不安定にするような使い方を始めました。
そうしたらものの見事にハマったので備忘録として書き残しておきます。
再現ジョブを作ったのでそちらで確認していきます。
まず、ビルドするソースコードはこちら
なんのへんてつもないコードです。
これを g++ -Wall -Wextra でビルドするジョブを作成します。
これを1回成功させておきます。
このときの警告は2件です。

続いて、新規警告が1件でもあったら不安定するように設定を変更します。
そして、ソースコードも以下のように書き換えます。
これを実行すると、結果は新規警告1件により不安定になります。
このとき警告の総数は3件です。

ここまでは、問題ありません。
次が問題です。
もう一度ジョブを実行します。
今度はソースコードを変えてませんので、警告数は3件のままで新規警告も 0件 のはずなので、成功になるはずです。ところが、実際には不安定になってしまうのです。なぜ?!



なぜか新規警告が1件と出力されています。
ビルド結果ページを見ると 0件 なのに?
どうやら、Warnings Plugin で見る新規警告は、最後の成功ビルドから見ての新規警告だったようです。
(ソースコード変更後の警告数は3件なので、成功時の警告2件からみると1件増えたように見える)
ログにもちゃんと
「Use previous build as reference」にチェックを入れるだけです。

この状態でもう一度ジョブを実行すると、意図通り成功になりました!


ログもこの通り、ちゃんと1つ前のビルドを参照しているようです。
説明が英語だったのでスルーしてましたが使いどころが分かりました。
また、どういう挙動をしているのか少し分かったことで、通知の仕方の幅が広がりました。
(成功時の警告数を下回るまで不安定するのもアリだと思った)
今回は以上。
では。
この機能を使って、警告が残っていたら不安定(黄)にすることが多いのですが、
最近になって、警告が増えたら(新規警告があったら)不安定にするような使い方を始めました。
そうしたらものの見事にハマったので備忘録として書き残しておきます。
新規警告がないにも関わらず不安定になってしまう!!
そんなことが起こってました。再現ジョブを作ったのでそちらで確認していきます。
まず、ビルドするソースコードはこちら
int main(int argc, char** argv)
{
return 0;
}
これを g++ -Wall -Wextra でビルドするジョブを作成します。
これを1回成功させておきます。
このときの警告は2件です。
続いて、新規警告が1件でもあったら不安定するように設定を変更します。
そして、ソースコードも以下のように書き換えます。
int main(int argc, char** argv)
{
int x;
return 0;
}
これを実行すると、結果は新規警告1件により不安定になります。
このとき警告の総数は3件です。
ここまでは、問題ありません。
次が問題です。
もう一度ジョブを実行します。
今度はソースコードを変えてませんので、警告数は3件のままで新規警告も 0件 のはずなので、成功になるはずです。ところが、実際には不安定になってしまうのです。なぜ?!
なぜなのか
ログを見てみましょう。なぜか新規警告が1件と出力されています。
ビルド結果ページを見ると 0件 なのに?
どうやら、Warnings Plugin で見る新規警告は、最後の成功ビルドから見ての新規警告だったようです。
(ソースコード変更後の警告数は3件なので、成功時の警告2件からみると1件増えたように見える)
ログにもちゃんと
[WARNINGS] Computing warning deltas based on reference build #9と書いてありました。
前回のビルドから見て欲しい
簡単でした。「Use previous build as reference」にチェックを入れるだけです。
この状態でもう一度ジョブを実行すると、意図通り成功になりました!
ログもこの通り、ちゃんと1つ前のビルドを参照しているようです。
最後に
「Use previous build as reference」とか、「Only use stable builds as reference」とか、説明が英語だったのでスルーしてましたが使いどころが分かりました。
また、どういう挙動をしているのか少し分かったことで、通知の仕方の幅が広がりました。
(成功時の警告数を下回るまで不安定するのもアリだと思った)
今回は以上。
では。
登録:
投稿 (Atom)