第7回大阪Jenkins勉強会を開催してきました #jenkinsstudy
だいぶ時間が経ってしまいましたが、去る2016年6月18日に、約2年半振りとなる大阪Jenkins勉強会の第7回を開催してきました。
今回はJenskins2のリリース記念ということでJenkins生みの親である川口さんと、現在開発中のJenkinsの新しいUI「Blue Ocean」の開発者であるJames Dumayさんをお迎えしました。
セッション
前半は実践系のセッション、後半はJenkins2を深く広い視点から解説するセッションという構成でした。
大畔 祐輝さん「初めての自動化、Jenkins」
- Jenkins2の導入時に躓きそうなところを実体験をもとにまとめて話して下さいました。
- 初めての発表とのことでしたが、丁寧な調査と落ち着いたしゃべりで素晴らしい発表でした。
@nobuokaさん「Jenkins Pipelines と Android アプリ開発 」
今日の発表資料です!
— Yu Nobuoka (@nobuoka) June 18, 2016
Jenkins Pipelines と Android アプリ開発 https://t.co/dArocoh0Db#jenkinsstudy
- @nobuoka
- Android開発でのJenkins活用事例を紹介して頂きました。
- Pipelineのハマりどころ、使ってはじめて分かる超絶便利部分など、なかなか聞くことの出来ない贅沢な内容でした。
@kazuhito_mさん「実録!となりのJenkins2.0」
本日発表する資料です。よろしくおねがいします♪
— 三浦 一仁(初学者) (@kazuhito_m) June 18, 2016
「実録!となりのJenkins2.0」 - 第7回大阪Jenkins勉強会 #jenkinsstudy #jenkins2 https://t.co/rSOztM8jq9
- 安定の@kazuhito_m。
- 会場を巻き込むしゃべりは流石でした。ちょっとやかましかったけど。
- デモ動画を流しながら解説するスタイルは非常に分かりやすかったです。ちょっとやかましかったけど。
- やってることもトリッキーなのによく考えられてて聴き応えのあるセッションでした。ちょっとやかましかったけど。
- ちょっとやかましかったけど。でもそれがいいw
川口耕介さん「Jenkins 2.0の紹介」
- @kohsukekawa
- Jenkinsの背景にある考え方、ビジョン、そしてJenkins2以降どうやって発展させて行くか、という内容を丁寧にお話して頂けました。
- Jenkins2のLTSも近くリリースされるそうなので、2.0への以降も進むと思います。
- 今後の発展がますます楽しみで、僕も少しでも貢献出来ればいいなって思います。
The first #jenkins2 based LTS release is now being tested (2.7.1 RC1)
— Jenkins (@jenkinsci) 2016年6月27日
James Dumayさん「Blue Ocean 〜A new user experience for Jenkins〜」
- @i386
- 現在開発が進んでいるJenkinsの新しいUI「Blue Ocean」についてどこよりも早い解説セッションでした。
- 開発車のJamesさんが英語で解説し、川口さんが逐次翻訳するスタイルでの発表でした。Jamesさんが日本語で挨拶したのを川口さんが英訳する場面もあり笑いを誘っていました。
- まだ開発中のBlue Oceanですが、実際に触ってみることも出来るので、気になる方は Blue Ocean を見てみてください。
- ちなみに、当日接続端子の都合で僕のPCを使って貰ったため、手元にはJamesさんのスライドがあったりします(役得)。
- さっそく試した方も。
ブログ更新。
— ずみっくす@NowIsTheTime! (@srz_zumix) 2016年6月28日
ブログズミ: [Jenkins] Blue Ocean を試してみる https://t.co/5NcR460IAp
@Posauneさん「Travis, Circle, そしてJenkins 2.0」
- こちらも安定の@Posaune。
- CIサーバとしてJenkinsが世界に与えた影響や問題点、昨今流行りのCIサービスについて、さらにそれらと比較したJenkinsの立ち位置などについて、独自の世界観と深い考察をお話くださいました。
- Jenkinsの属人化問題は僕も頭を悩ませる問題で、Pipeline Scriptによるコード化が有効な手段になりうるかもと期待しています。
LT
僕「Jenkins2.0で雑にLTタイマー作ります」- Vagrantを使った自動化デモ。
- ArduinoでXFDデモ。
- Jenkinsで彼女作ったら温もりが足りなかったり。
- @kiy0takaさんのBlueOceanハックLTにテンション上がりまくりのJamesさん。
Oh my this is AMAZING!!!!! @jenkinsci #jenkinsstudy #blueocean pic.twitter.com/CQo8VJfuhi
— James Dumay (@i386) 2016年6月18日 - いろふさんはとんでもない速度でコミットフックでビルドするところまでジョブ作ってた。
- 制限時間なんてなかった。
とにかくハイレベルで自由なLTでした(僕除く←)。
大阪Jenkins勉強会のLTのレベルが高すぎる #jenkinsstudy
— Kohsuke Kawaguchi (@kohsukekawa) June 18, 2016
そのほか個人の感想など
- 久しぶりに大阪でJenkins勉強会を開催することができました。
- 初めてのJenkinsあり、Android開発での利用事例あり、企業内での縛りプレイ的な状況でのJenkins利用例ありでバラエティに富んだ内容を実現することができました。
- 今回の勉強会で得られたこと、学んだことを現場でも実践して頂ければ、それ以上嬉しいことはありません。
- あわよくば、次回の勉強会でその実践事例を発表してもらいたいです。
- いつの間にか主催側になって、あれよあれよというまに川口さんとJamesさんに来てもらえる事になって、最終的には大盛況で終えることができました。遅くなりましたが本当にありがとうございました!
ブログ記事
勉強会の感想も書いてくださっています。
#jenkinsstudy 第7回大阪Jenkins勉強会は、Jenkins入門から始まり、彼女を作ってぬくもりが足りず、Blue Oceanのハックで終わった1日であったよ! - M…https://t.co/y3TyTmYswg
— Mitsuyuki.Shiiba (@bufferings) June 19, 2016
ブログ更新。
— ずみっくす@NowIsTheTime! (@srz_zumix) June 20, 2016
ブログズミ: 「第7回大阪Jenkins勉強会」に行ってきた https://t.co/YxUX3tCFtz
参加してきました。Jenkins2.0になってかなーり良くなってるぽい。そしてBlue ocean UI早く使いたい!#jenkinsstudy
— naichi (@naichilab) June 18, 2016
2016.06.18 第7回大阪Je…https://t.co/QXTwmg9Png
コマンドプロンプトの errorlevel を確認してエラーなら処理を終了する方法
基本中の基本なんですが、最近はエラーが起こったら処理を終了することが重要になってくるとき、例えば「コマンドプロンプトしか使えない状況でCI回したい」みたいな縛りプレイしてるときに使ってます。具体的にはJenkinsのジョブを失敗させるためですが。
手順
まず、バッチファイルに以下の様なサブルーチンを用意しておきます。
:SuccessOrDie if not %errorlevel% == 0 ( echo [ERROR] :P exit 1 ) exit /b 0
これをerrorlevel
に戻り値を返すコマンドのあとにcall
で呼び出します。
xcopy src\hoge.dll dest\ /Y /F call :SuccessOrDie
もしエラーが発生していたら(errorlevel
が0
でなかったら)exit 1
が実行されコマンドプロンプトが戻り値1
、つまりエラーで終了します。Jenkinsだとこれだけでジョブを失敗させることができます。
一方、エラーがなかった場合(errorlevel
が0
の場合)はexit /b 0
が実行されます。/b
オプションによってサブルーチンを終了し呼び出し元に戻ることができます。
バッチファイルではよくgoto
使ってエラー処理をしているのを見かけますが、呼び出し元に戻りたいのに加えて、思わぬバグが生まれることがあるので使うのを避けて、call
とexit
の組み合わせを使っています。
errorlevelを含む条件式での注意点
if not errorlevel 0 exit 1
って書いてしまうと「0以上ではないとき終了する」になるので、errorlevel
が負のときにしかexit
が実行されません。
if not %errorlevel% == 0 exit 1
というように展開した上で文字列での比較を行うことで「0ではないとき終了」するようになります。
手動で実行したい!
基本的にはCIサーバでコンソール出力を記録しながら使うことを前提としたバッチファイルですが、CIとかよくわからんから手動でもログを残して実行できるようにしておいてくれないと困るって言う人が稀によくいます。
そういうときは以下のような処理を書いた手動実行用のラッパーを用意しています。
@echo build.batを実行します。 @echo ログは build.bat.logに出力されます。 @pause @echo 実行中... @call build.bat > build.bat.log 2>&1
このバッチファイルをダブルクリックするだけでログ出力まで行います。
サンプル全文
ここまでで紹介したあれこれをまとめたサンプルの全文です。
@echo off set SELF_PATH=%~dp0 cd /d %SELF_PATH% xcopy src\hode.dll dest\ /Y /F call :SuccessOrDie goto end :SuccessOrDie if not %errorlevel% == 0 ( echo [ERROR] :P cd /d %SELF_PATH% exit 1 ) exit /b 0 :end echo [SUCCESS] :) echo on exit 0
第6回 PowerShell勉強会 に参加してきました #jpposh
第 6 回 PowerShell 勉強会 - Japan PowerShell User Group (JPPOSH) | Doorkeeper に参加して、LTでPesterについて少しだけ話をさせてもらって来ました。
LT資料はこちら。
せっかくなので、ちょっとLTの補足なんかをしておきたいと思います。
TestDrive
TestDriveにアクセスするときTestDrive:\
か$TestDrive
が使えますが、微妙に異なる点があります。
前者は通常のPSDriveですが、後者にはTestDriveが指す場所のフルパスが入っています。
そんなに困ることは無い気がしますが、一応覚えておいた方がいいかと思います。
コードカバレッジ
二点ほど。
まず一点目。Pester自体はPowerShell2.0以上で動作するんですが、コードカバレッジ機能だけはPowerShell3.0が必要です。そんな環境でPester使うことあるんかって話は置いといてください(ニッコリ。
もう一点は計測結果に出てくる 「commands」 についてです。資料の中では
Code coverage report: Covered 66.67 % of 3 analyzed commands in 1 file.
って出てるやつです。
Pesterのコードカバレッジの計測はPSBreakpoints
で実行されたcommand(文)を記録することで実現されています。実行されたPSBreakpointsがcommandsとして報告されます。
そのためPowerShellの仕様としてPSBreakpointsが置けないelse
やtry
、finally
なんかはcommandsにカウントされません。if
とかthrow
とかreturn
とかはカウントされます。
コードカバレッジの結果を見て数が合わないなって思ったときは、一度確認してみてください。
ほかの方々の資料
は、こちらから
Jenskinsでのsvnリポジトリのポーリングで発生するエラー
Jenkinsでsvnをポーリングするようにしていると、以下の様なエラーが発生することがあります(「Subversionのポーリングログ」から確認できます)。
ERROR: Failed to check repository revision for proto://host:port/path/to/repo
org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
数日前からこのエラーが起きてたのをようやく解決できたのでメモしておきます。
このエラーは svn:externals を使って別のリポジトリを参照する構成になっている場合で、メインのリポジトリと、参照先のリポジトリの認証情報が異なるときに起こるとのこと。
- [JENKINS-21785] Check for changes in folders linked via svn:externals fails due to missing credentials - Jenkins JIRA
- Subversion Plugin - Jenkins - Jenkins Wiki
実際にエラーが発生した環境は、メインも参照先も同じサーバのリポジトリで同じ認証情報だったので、 あまり気にしたことなかったんですが、Jenkinsから外部リポジトリの更新を行う時には通常とは異なる動きでsvnクライアントが 起動するらしく、何らかのタイミングでメインのリポジトリと参照先のリポジトリの認証情報に齟齬が発生していたようです。
正しく動作させるにはジョブの設定で [Additional Credentials] を追加し、外部リポジトリのrealmというのと、それに紐付いたCredentialsを指定します。
realmの確認は以下のコマンドで出来ます。ダイアログが出てくるけどキャンセルでいいです。
svn --no-auth-cache --config-dir invalid info proto://host:port/path/to/repo
この問題は、今回みたいに同じsvnサーバ上のリポジトリでも起こりえるので svn:externals を使っているリポジトリをJenkins で触るときは必ず [Additional Credentials] を指定しておくのが正解っぽい。
tscとlite-serverで作るシンプルなTypeScript開発環境
最近MacでカジュアルにTypeScriptを書いてブラウザで確認したいなってときに使っている環境です。 ぶっちゃけAngular2の 5 Min Quickstart で使われている方法ですが。 (なお、前提としてnode.jsをインストールしてnpmを使えるようにしておく必要があります。)
使用するツールはTypeScript(tsc)の他には lite-serverという開発用のhttpサーバだけです。 上記二つを使って、[TypeScript書く] > [自動ビルド] > [ブラウザの自動リロード]を実現していきます。
まず、実験用のディレクトリを作ってTypeScriptをインストールしておきましょう。
mkdir my-proj cd my-proj npm install typescript
これでTypeScriptをコンパイルするコマンドtscが使えるようになります。
適当に以下のような sample.ts
を作って node_modules/.bin/tsc sample.ts
を実行すると sample.js
が出来ますね。
class Person { public Name:string; constructor(name:string) { this.Name = name; } } var me = new Person("Hidari"); document.body.innerHTML = me.Name;
さて、tscには -w
オプションがあり、tsファイルの変更を検知してコンパイルを自動で行うことが出来ます。
これを行うために、まず tsconfig.json
というファイルを sample.ts
と同じ場所に作成し、以下の内容を記述します。
{ "compilerOptions": { "module": "commonjs", "target": "es5", "rootDir": ".", "outDir": ".", "noImplicitAny": false }, "exclude": [ "node_modules" ] }
ファイルが作成できたら node_modules/.bin/tsc -w
を実行してみましょう。
tsファイルの変更が監視されます。試しに sample.ts
を変更してみてもいいと思います。
次にlite-server。これはnode.js上で動作する開発用のhttpサーバで、ファイルの変更を検知してブラウザで表示中のページを自動でリロードしてくれます。
npm install lite-server
でインストール。
続いて適当に以下の様な index.html
を作り、新しいターミナルでnode_modules/.bin/lite-server
を実行します。
するとブラウザが開いてindex.htmlが表示され、同ファイルの変更監視が開始されます。
<!DOCTYPE html> <html> <head> <title>sample</title> </head> <body> <script src="sample.js"></script> </body> </html>
以上で終わりです。
これでTypeScriptを編集すると自動でコンパイルされ、ブラウザがリロードされ、結果が確認出来るようになりました。 ガッツリ開発するにはちょっと力不足ですが、雑に書くぶんには十分だと思います。
ではでは。
CI勉強会に参加してきました #vshtc
びっくりするほどほったらかしになっててびっくりしました。
今日はVSハッカソン倶楽部主催のCI勉強会 - #vshtc - VSハッカソン倶楽部 | Doorkeeperに参加してきました。
会の構成としてはセッション4つと、今後計画されている「XFDハッカソン」のためのアイデアソンという形で、僕はセッションの一つで主催の森理 麟 (@moririring)さんと共に発表させてもらいました。
セッション部
一つ目のセッションは、Yu Nobuoka (@nobuoka)さんによる「CI のすすめ 〜はてなでの web サービス・モバイルアプリ開発と CI〜」。 はてなでのCIについてどんなふうに行っているのか、なぜCIが必要なのかといった話で、めっちゃ勉強になった!!
2つ目はLibreぽざうね (@Posaune)さんによる「ポストJenkins時代のCI戦略」。若干煽り気味のタイトルですが、内容は安定のPosauneさんクオリティ。毎回情報のカバレッジに驚かされ続けています。詳しくは公開されているスライドポストJenkins時代のCI戦略を見てみてください。
3つ目は我らが森理 麟 (@moririring)さんと、不肖わたくしによる「WindowsでbatとPowerShellでCI!」。前半が森理麟さんによるbatファイルとタスクスケジューラによるローカル環境CIについてデモをメインに紹介。後半で僕がPowershellを使ったWindows環境でのビルドについてデモを行いました。ほどんどスライドを使わないほぼ無刀セッションでしたが、なかなか興味を持ってもらえたようでありがたい限りです。
4つ目は三浦カズヒト(「らむだ」とか解らない人) (@kazuhito_m)さんによる「出来る!XFD!」。このセッションが次の「XFDハッカソン」につながる大きな布石となっています。こちらもスライドができるXFD - 2015/07/11 CI勉強会 - #vshtcで公開されているのでそちらを参照ください。パトランプ!パトランプ!
アイデアソン部
アイデアソンとはハッカソンで作るもののアイデアをみんなで出し合っていく話し合いみたいなもの。数人でグループを作ってブレインストーミング的なことを行ってアイデアを出し合い、10分程度話し合ったらまた別のグループを作ってアイデア出し、という形式で計3回行われました。
XFDとしてどんな情報をFeedbackするのか、どんな方法でFeedbackするのかをわいわい出し合い、荒唐無稽なものからわりと現実味のあるものまでいろんなアイデアが出て楽しかったです。僕が参加したグループで出たのアイデアの一部としては
- ビルドがコケるたびに連絡先を一個ずつ消していく
- ビルドを壊した人をイニシャルで指摘
- ビルドを壊した人のチャットなどのアイコンを「僕がやりました」を表すものに変える
- ビルド成功などのたびにコーヒーの温度が5℃ずつあがり、一定の成果を出すとコーヒーが飲める
- ビルド成功などのたびにキャラクターが褒めてくれる
- プロダクトのモジュール図などで壊れている部分を赤くして他のチームに知らせてしまう
- ビルド失敗などのたびにHPゲージが減って全損するとモニタの電源が落ち、復活させるにはチーム全員でKinectで変なポーズを認識させる
などでした。
おわりに
僕の発表はほぼ全部デモということもあり、いろいろ不安要素も多く中には実際に現実に上手くいかない部分もありましたが、予定していた内容は実行出来たので自己評価はなかなか(甘めですが)。反省としてはもう少しスムーズにデモをやると、時間を有効に使えるし、魅力ももっと伝えられるだろうなってところです。
アイデアソンで出たアイデアは終盤にはかなり現実的なものに落とし込まれていて、参加者のレベルの高さを感じました。同時にハッカソン、ついていけるかなっていう不安も出てきました…。でもそれよりも早く動いてるところを観たいという気持ちが強く、とても楽しみです。
参加者の皆様、お疲れ様でした。
おまけ
懇親会でなぜか最近面白かった漫画を紹介する流れになったので、そこで出した本をご紹介。
- 作者: 九井諒子
- 出版社/メーカー: KADOKAWA/エンターブレイン
- 発売日: 2015/01/15
- メディア: コミック
- この商品を含むブログ (104件) を見る
- 作者: 芝村裕吏,キムラダイスケ
- 出版社/メーカー: 講談社
- 発売日: 2014/01/10
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 梅田阿比
- 出版社/メーカー: 秋田書店
- 発売日: 2014/02/14
- メディア: Kindle版
- この商品を含むブログを見る
ではでは。
JavaScriptだけでブラウザの「戻る」ボタンを無効化する方法
このあいだ諸事情で調べたら、意外とまとまってるとこなかったなのでちょこっと書いてみます。
- IE8以降を対象
- ブラウザの「戻る」ボタンで他のページに遷移しない
- Backspaceキーでの「戻る」も許可しない
みたいな方針で調べてみました。
まあ結論から言うと
Ah, the back button. You might imagine "back" fires a JavaScript event which you could simply cancel like so:
document.onHistoryGo = function() { return false; }
No so. There simply is no such event.
というわけで、ブラウザの戻るボタンをお手軽に無効にする方法はないようですね。
方法
1.window.onunload
イベントを利用する
まず直接的なイベントが無いなら似たようなイベントをかわりに使おう!みたいな安直な発想で。
ページから離れる際に発生するonunload
イベントをトリガーとして、次に表示されるページ(遷移先)を現在のページにしてしまう関数を実行する方法。
window.onunload = function() { alert('Back buttom is pushed ??'); location.replace(document.location); };
onunload
は戻るボタン以外でも発生するの。Backspaceキー、URLの直接入力、履歴からの遷移でも。リンクをクリックしたときも当然発生する。その結果、このコードがあるページからは移動できなくなるという仕組み。
対象を「戻る」ボタンの動作だけに絞ることができないので、この方法はちょっと厳しそう。
以下のように、適当なタイミングでイベントハンドラを削除することで移動できるようにすることもできなくはないけど、釈然としない。
<script type="text/javascript"> function goNextPage() { window.onunload = null; }; </script> <a href="./Page3.html" onclick=" goNextPage(); ">Go Next</a>
というかIE11ではlocation.replace()
でランタイムエラーになって動かないんだよな…(だめじゃん
参考:ブラウザの戻るボタンを無効にする方法: ある SE のつぶやき
2.history.forward()
関数を使う
検索するとよく見つかる方法。遷移元のページに 以下のJSを記述しておく。
window.onunload = function() {}; history.forward();
上のコードがhead要素辺りに書いてあるページAからページBへ遷移、その後Bから「戻る」ボタンでAへ戻ると、history.foward()関数でBへ送り返されます。なので、Backspaceキー使われても平気。
ただ、履歴の一つ前がAのときはBからだけでなくどのページからも戻れないことになるので、特定のページだけ「戻る」ボタンを使用不可にしたい!みたいな状況では使えない。
逆にこのページだけには戻ってきてほしくない、っていうときは、あるいは使える?
参考:[JavaScript] ブラウザの戻るボタンを無効にする方法 | 自由が丘で働くWeb屋のブログ
3.window.location.hash
を使う
URLにhash(URLの後ろにくっつく#HogeHoge
みたいな文字列で、ページ内リンクなんかに使われてる)をつけることで別ページへの遷移として履歴に残して、他のページに戻れなくしてしまう方法。
window.location.hash="no-back"; window.location.hash="no-back-button"; window.onhashchange=function(){ window.location.hash="no-back"; }
ページが読み込まれたタイミングでURLの末尾に#no-back
、あるいは#no-back-button
を追加し、同時にhashが変更されると発生するonhashchange
でhashを変更する関数を追加する。
ページに遷移してきた時点で、履歴の一つ前のページが自分自身になっているため、戻るボタンを押しても自分に戻るだけになるという寸法。
URLに余計な文字列が含まれてしまうのを嫌がる人もいますが、先に挙げた方法よりだいぶ安定している印象ですね。
参考:javascript - How to Detect Browser Back Button event - Cross Browser - Stack Overflow
4. history.go()
を使う???
+JavaScript+ブラウザの戻るボタンの無効化 - Free Flying
こういう方法もあるみたいだけど、なんでhistory.go()
で「戻る」が使えなくなるのかイマイチ分からなかったんで試すのをやめました。
参考:go method (Internet Explorer)
5. HTML5の History API を利用する
今回僕が当たった要件では難しいけど、HTML5が利用できるIE10以降では以下の方法を使えば、概ねそれらしく動きます。
「戻る」を禁止したいページに以下のJSを書く。
<script type="text/javascript"> history.pushState(null, null, null); window.addEventListener("popstate", function() { history.pushState(null, null, null); }); </script>
ページが読み込まれたらhistory.pushState()
メソッドで履歴の先頭に新しい履歴がひとつ追加される。このとき第3引数がnull
なので、追加された履歴は自分自身を指していることになる。続いてpopstate
イベントのハンドラとしてhistory.pushState()
を実行する関数を指定する。
「戻る」ボタンが押されるとpopstate
からイベントハンドラが実行され、自分自身を指す履歴(history.pushState(null, null, null)
)がもう一つ追加される。
ページ読み込み時に実行されるhistory.pushState()
では、最初に「戻る」が実行されたときに戻る先の履歴が追加され、2回目以降の「戻る」実行時はイベントハンドラで追加される履歴が使用される、はず。
戻る先は常に自分自身になるため、結果として「戻る」ボタンを無効化できます。先に書いたlocation.hash
に近いもので、実際リファレンスには
ある意味では、pushState() の呼び出しは window.location = "#foo"; と設定するのと似ています。どちらも、現在のドキュメントに関連する別の履歴エントリの生成とアクティベートを行います。
Manipulating the browser history - Web developer guide | MDN
とあるので、HTML5が使えるならhistory.pushState()
、ダメならlocation.hash
を使うというのが、ある意味正攻法なのかも。
まあ、各種イベントの発火条件とかに違いがあるので、よく考えて使う必要があるのは言うまでもないのですが。
参考:
おわりに
かろうじて使えるかなって言うのがlocation.hash
を使う方法でしょうか。
というかそもそもですね、特にレガシーな感じのブラウザで、「戻る」ボタンの無効化くらいJavaScriptだけでできるんでしょ?ちゃちゃっとやっちゃって?という、(冒頭の引用のような)安直な考えは捨てるべきなのではとか思わずにはいられないと思ったり思わなかったり。