- 継続的インテグレーション (CI) を啓蒙するスレ
2 ：デフォルトの名無しさん[sage]：2018/02/18(日) 00:08:48.88 ID:dp9S/ZRw - あるならあるで良いんだが、効果は限定的だと考えるようになってきた。
なぜならCIで実行するものは何かというと通常テストの実行だが、
テストの実行というのはどちらにしろローカルでも行うから
「テストを実行するの忘れない」とか「みんなが見れる場所でテストが実行されている」
というメリットは有るのだが品質にはあまりつながらない気がする。
もちろんローカルでやるのが大変なものを、CIだと簡単にやれる
という状況であれば効果は高いのだが、ローカルでやるのが大変なものってなんだ？
それがCIで簡単にやれるためには相当ハイスペックなマシンが必要じゃないか？
みたいになる。
重要なのはCIで実行する「内容」であって、CIという手段ではないので、
あまり手段にこだわってもなぁという気がしている。
もちろんあるのとないのではあったほうが良いんだよ。でもアレば少しマシぐらいの感覚
|
- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
919 ：デフォルトの名無しさん[sage]：2018/02/18(日) 02:19:09.25 ID:dp9S/ZRw - >>918
今、話をしてるのはクローラーの話だって分かってない？
クローラーはクッキーやローカルストレージは使わない
https://www.suzukikenichi.com/blog/googlebot-uses-a-web-rendering-service-that-is-based-on-chrome-41/
ページレンダリング中に一時的に使ってるかもしれないが読み込み時に毎回クリアされる
クローラーっていうのは、HTMLを取得（ページをレンダリング）する処理と、URLをかき集める処理が別れている
そしてクローラーは自分が知ってるURLに対してGETリクエストを送る
だから一回もリクエストを送らないということはありえないんだよ。
クローラーはブラウザじゃない。ブラウザのように前の状態というのを持たない。
だからアプリの作りが例えサーバーと通信しない作りであっても
知ってるURLに対して初回アクセスと同じようにかならずGETリクエストを送ってくる
そしてクッキーやローカルストレージは持たない
クローラーは必ずSPAのアプリケーションの特定のURLに対して直接GETでアクセスしてきており
（アクセスしない ＝ 最新の情報がわからないのだからクロールされてるページ内容の更新を行わない）
なおかつ初回アクセスと同じようにデータは空なのだから、状態は200か404のどちらかに決定することが可能
（まあ他にもリダイレクトとかあるだろうけどいずれにしろどれかに決定できる）
クローラーがブラウザと同じようにクライアントサイドだけでアプリを動かしているかもしれないじゃないか
とか頓珍漢なこと言うなよ？ それなにもクロールしてないからｗ クローラーの使命を果たしていない
|
- 継続的インテグレーション (CI) を啓蒙するスレ
7 ：デフォルトの名無しさん[sage]：2018/02/18(日) 02:48:20.51 ID:dp9S/ZRw - 先に>>6に言われたなｗ
例えばgoはコマンド一つで複数のプラットフォーム用のバイナリを生成することができる
CIはビルド&テスト&デプロイをやってくれるものだと考えているかもしれないが、
別に自分のマシンからだってビルド&テスト&デプロイは行える
つまりCIの価値というのは、ビルド&テスト&デプロイそのものではなくて
ワークフローを統一化できるというところにある
それはそれで良いことなんだが、CIのメリットというのはワークフローの統一化だと思うと
思っているほど大したことしてないと思うだろ？
そしてもう一つは、テストマシンリソースのレンタル
テスト自体は自分のマシンでできる。だけど自分のマシンで追いつかないようなものは、
CIサーバーに頼んで借りられる。ただしCIサーバーのスペックが高いか、
クラスタでも組んでないと自分のマシンでやったほうが速いってことになりかねないｗ
ちなみに普段の開発中にはCIは利用しない。なぜならCIでは特定のメソッドだけテストの実行を行う
なんてことがやりづらく自分のマシンでテストを実行したほうが速いから。
CIによるテストは時間が掛かるテストをお行うもので、時間がかからないテストはローカルで済ませる
>>5
> テスト要員を半分以下に。単純作業のテスターは要らない。
それを実現するにはCIサーバーを導入しても実現できない。
単純作業（テスト）を行うためのテストコードが必要。
だがテストコードがあるなら、それは自分のマシンでも実行できる
|
- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
923 ：デフォルトの名無しさん[sage]：2018/02/18(日) 13:52:18.73 ID:dp9S/ZRw - >>920
長時間クロールっていうのはたくさんのページを
まとめてクロールしてるってだけ。動きは変わらない。
> クローラが一般的にそうである必要はないよ
個人的にしか使わないクローラーは別として
一般的なクローラーは、不特定の人が見るわけだから
このような動きになる。
|
- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
924 ：デフォルトの名無しさん[sage]：2018/02/18(日) 13:52:56.22 ID:dp9S/ZRw - >>922
なんかいえやｗ
|
- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
926 ：デフォルトの名無しさん[sage]：2018/02/18(日) 13:59:45.98 ID:dp9S/ZRw - >>921
SEOの話とは違うね。
ページが見つからない時、どうやって404を返すべきかどうかの話
SPAがどうたらとか、サーバーにアクセスしないときがどうとか
言っているが、それらは全く関係ないってことを言ってる。
普通にサーバーにアクセスされた時にデータがなければ404を返せばいい
どんなページもURIを持っていればサーバーにアクセスされうる
（その典型的な例がクローラーってだけの話）
サーバーにアクセスしないときは〜なんて考える必要はない。
そもそもアクセスされないなら何も出しようがないだろ？
|
- + JavaScript の質問用スレッド vol.124 + [転載禁止]©2ch.net
927 ：デフォルトの名無しさん[sage]：2018/02/18(日) 14:07:51.73 ID:dp9S/ZRw - >>925
> 要はURIだけで画面が作れる画面ってのはあるんだよ。
> URIがデータの時な。
URIがデータだったとしても、（そもそも全てのURIがそうなんだがｗ）
話は関係ない。
URIを持っていればサーバーにアクセスされうる
SPAの場合にサーバーにアクセスしない場合もあるってだけで
ブラウザでF5を押したりクローラーからアクセスされる。
だから必ずしも作る必要はないが、ちゃんと作るならば
サーバー側の処理は必要。その時にデータがなければ404を返せばいい
（URIの情報しか使わないというのならそれは200だろうけどな）
> クローラはブラウザセッション、状態をすべて忘れてそのURLをレンダリングするんだぞ。
> SPAなんにもわかってねえな。
そもそもレンダリングする前に、クローラーはSPAであることもわすれて
URIに対してサーバーにアクセスする。ここでSPAのことを考えること自体が意味ないんだよ
ちゃんと作るならば、サーバーにアクセスされた時に必要なデータがなければ404を返せばいいだけ
データの有無の話でAjaxによるアクセスかどうかとかの違いも考える必要はない。
どんな内容を返すか？のために考えるのであって、データがないときは404
|