00:06
8月3日、水曜日ですね。地獄は朝9時を回りました。
今日も、なかなかいい天気になりそうなんていう感じですね。
はい、おはようございます。夢見のkkeethことくわはらです。
はい、では本日の朝活を始めていきたいなと思います。
えっとですね、今日はタイトルがありますけど、
ハイドレーションとかハイドレートってよく出てくるんですけど、
この辺が、よく分かってるって分かっとらんので、その辺の記事をちょっと読みたくなったって感じです。
一応、一度は読んだり勉強はしたんですけど、
結局僕の中では腹落ちしてないなってのもあったので、
読んでみたいなと思いました。
特にその中で、一つが日本語のほうの記事で、
もう一個のほうが海外の記事なんですけど、
JavaScript Hydration Is a Workaround, Not a Solution っていう記事があって、
このタイトル見た瞬間、もう一枚盛りだしたので、
これをちょっと今日読みたいなと思った次第であります。
はい、おはようございます。
しゅうゆうせんさんとけいさんと、杉山としきさんと、
これちょっと読み方が分からなくなっちゃった。
ドクマさんですか、ディクマさんですか、
ちょっと読み方が分からないですけども、
はい、朝からご参加いただきありがとうございます。
今日はひたすらハイドレーション系の記事を読んでいこうかなともいいます。
ではですね、早速一つ目のほうからやっていきたいと思います。
リアクトであるハイドレートで何でしょうかっていう問いですね。
これはQuoraっていうサイトがあると思います。
そこに投げられた疑問について回答していくっていう感じですね。
はい、ちょっと待ってくださいね。
なんか音声がよろしくないみたいなのが流れてきているので、
そうですよね、入力が間違ってましたね、これは。
はい、というところです。
じゃあここで入力を変えて、出力はこのままでOKですね。
OK、じゃあこれでいきましょう。
はい、問いはそのままですね。
リアクトであるハイドレートで何でしょうかっていう問いですね。
それに対していくつか回答があるんですけども、
面白かったやつがあったのでこれを読んでいこうと思います。
一つ目の回答ですね。
SSR、サーバーサイドレンダリングにおけるとある処理のことを言ってますと。
以下に解説している段階のステップ4の処理だと言ってますけど、
そこをちょっと1個ずつ段階を追って読んでいきましょうか。
サーバーサイドレンダリングで返すHTMLと従来のPHPなどで返すHTMLファイルの違いとか、
またその仕組みが分かってないですと。
結果的に同じHTMLを返すのに何が違うんでしょうかっていう問いに対する回答があって、
それの4番目がいわゆるハイドレーションの話だよというふうに今回言ってますと。
そうですね、そこも一緒に読んでいきたいと思います。
リアクトアプリはSPAと言って、画面構造のDOM構築をブラウザー内でJavaScriptが実行します。
SPAではない従来のウェブアプリっていうのは画面構造のDOM構築っていうのをブラウザのHTMLパーサーが行います。
ここまではいいでしょうかと。
PHPはいわゆる公社の方ですよね。
パーサーの方で行うってところは公社ですと。
サーバーサイドレンダリングっていうのはSPA起動方法のバリエーションの1つで、
リアクトで言えば1番、利用者がウェブサーバーに初回アクセスしたときに、
サーバーサイドのJS実行系、いわゆるNodeだったりAWSAMだったりEdgeサーバーだったりNext.jsだったり、
ほげほげみたいなもので実行するものであって、
リアクトアプリを実行してDOM構築、さらにDOMをレンダリングしてHTMLを文字列として生成、
03:03
RenderToStream、またはRenderToNodeStreamっていうのをやって、
ブラウザにHTMLとして変形をします。
2番として、ブラウザでHTMLとして受け取って、
ブラウザがレンダリングして画面表示をします。
このときにHTMLの要素にNodeIDとかが付与されていて、
リアクトの仮想DOMの処理における差分検出の準備をしています。
3番として、このHTMLにはコンパイルされたリアクトアプリ及びランタイム、
バンドル.jsっていうのがJavaScriptとして付与されていて、
遅延ローディングが設定されております。
4番ですね、ここがメインなところになります。
バンドル.jsをロード後にリアクトアプリがブラウザ内で再度実行され、
SPAとして起動します。
このときブラウザ内で仮想DOMを生成した上で、
DOM生成しようとするんですけども、
常にですね、作られているDOMとの差がなければDOM生成は何もしない、
一般にはそうなります。
さらに要素に対するリアクトアプリとしてのイベントリーツナーのアタッチとかも行われます。
ちなみにこのステップをハイドレイトと呼ぶっていう風に言ってますね。
加えて5番ですね。
5番として、加えてReduxなどの状態管理ライブラリを併用しているときに、
サーバーサイトでReduxが初期生成した状態データをクライアントに転送し、
実行継続を行うこともできます。
こんな感じです。
PHPと同じなのが1だけです。
SSRっていうのはSPAの初回画面生成の時間を短縮したり、
SEOをするための最適化が一つと考えると今のところは良いでしょう。
SSRで返されるHTMLがPHPが返すHTMLと違っているのは、
まず生成されるのが初回アクセス値だけだということで、
SPAの実行の開始後にはアプリの画面遷移があっても二度とHTMLを取得しにいかないこと、
またHTML要素にリアクトの仮想DOM処理やイベントリストのアタッチのためのIDが振られているということです。
なおリアクト例にとって話しましたが、
他のSPAフレームワークやライブラリで仮想DOMを使うもので実装されているSSRも大体同じですけど、
よくは知らないよという話でした。
さっきの4番というのをもう一回ピックアップしますと、
bundle.jsロード後にリアクトアプリがブラウザ内で再度実行され、
ASPとして起動します。
このときブラウザ内で仮想DOMを生成した上で、
DOMを生成しようとするけど、
すでに2で作られているDOMとの差がなければDOM生成は何もしません。
2で作られているというのは、
いわゆるブラウザをHTMLとして受け取って、
ブラウザがレンダリングして画面表示をしています。
そのときにHTMLの要素にノードアイディを付与して、
仮想DOMの処理の準備をしますよというところですね。
というのが2番でした。
2が作られているDOMとの差分がなければDOM生成は何もしない。
一般にはそうなる予定です。
さらに要素に対するリアクトプリとしての
イベントリリースなどのアタッチなどを行いますけど、
このステップのことをハイドレートと呼びますよというところですね。
SSRにおいてサーバーサイドでリアクトが生成したDOMを
レンダートストリングなどで文字列化するのが
いわゆる脱水化、ハイドレーション、ディハイドレートというやつですね。
それを受け取ったブラウザがHTMLとしてパースして
復活させたDOMの最後の段階でイベントを受け取れる生きたDOMとして
再開させることをハイドレートと呼びます。
06:02
厳密に言うとリハイドレートしてもう一回ハイドレートするということですね。
急速真空、乾燥したインスタント麺を
熱湯散布で元通りの味と香りにするようなものです。
という最後の例えがなかなか秀逸で面白いなと思いました。
なるほどね。
そういう言い方をすると、なんとなくイメージしやすいからね。
はい、というところです。
なかなかへーっと思いますけど。
確かにこの説明は少し分かりやすいというか、
厳密すぎじゃない方からするといろいろ言いたいことあるんでしょうけど、
とりあえずまずハイドレートってどういうものかっていうのをイメージするという意味で
この説明はすごく分かりやすくて面白いなと思いました。
これ後ほどツイートさせていただきますので、
興味ある方はまた改めて読んで、
自分の中で腹落ちさせていただければなと思います。
ソースコードも一気に出てこないので、
なんか読むだけでいいので、なかなかいいんじゃないかなと思いました。
ではもう一個の方の記事ですね。
Javascript Hydration is a workaround not a solutionですね。
ソリューションではないよというところのお話を書かれている記事を読んでいこうと思います。
今回の記事の執筆者の方は、
何人か分からないですけど、アンギュラの中の人っぽいですね。
ミスコ・ヘベリーさんという方ですかね。
この方はチーフテクノロジーオフィサーアットビルダードットアイオーですね。
azctoですね。という方です。
一旦読んでいきましょう。
ビルダーズドットアイオーか。
なかなか激強そうな方ですね。
しかもその中のそのCTOですもんね。
じゃあ行きましょう。
ウェブ開発において、ハイドレーションとはサーバーでレンダリングされたHTMLに
インタラクティブ性を持たさるための手法の一つになります。
これはクライアントサイドのJavascriptがHTML要素にイベントハンダラーをタッチすることで
静的なHTMLウェブページを静動的なウェブページに変換する技術だと言っています。
ここまでは先ほど読んだやつと大体一緒ですね。
一応ハイドレーションというところの記事のリンクも貼られています。
このリンク先はやはり同じ、builders.ioの
Why Processive Hydration is Handler Than You Thinkという記事のリンクになっていますので
ここはちょっと後で、多分今日の時間は読めないと思うのでリンクは共有しますね。
もしくは明日読むかもしれないです。
はい、というところで冒頭はそんな感じです。
じゃあ早速記事の中に入っていきたいなと思いますね。
はい、まずハイドレーションの概要の話をしました。
しかしですけど、ドキュメントオブジェクトモデル、いわゆるDOMに
イベントハンダラーをタッチすることはハイドレーションの最も難しい部分であり、また高価な部分でもありません。
この記事ではなぜハイドレーションがオーバーヘッドになると私が考えるのかを説明していきます。
これは解決策ではなく、特にモバイルでメモリを消費し起動を遅くするハックになりますと。
この記事のためにオーバーヘッドを避けることができ、なおかつ同じ最終結果につながる作業と定義しておきましょうというふうにおっしゃられています。
はい、なるほどでした。
では、いきましょうか。
09:02
いかず、僕のようなネットワークが遅くて、今変換が遅いんですけども、いきたいと思います。
ディギングディーパーイントゥハイドレーションですね。
日本語を訳すると水分補給の深掘りって書いてて、すごい微妙な翻訳だというか、訳さなくてよくないみたいなところはありますけどね。
はい、まずちょっとやっていきましょうか。
ハイドレーションで難しいのは、どのイベントハンドラーが必要で、どこにつける必要があるのかっていうのを知ることだっていうのがまずスタートから入ります。
で、WATとWEARで2つに分けられてますけど、まずWATですね。
イベントハンドラーはイベントの振る舞いを含むクロージャーになりますと。
ユーザーがこのイベントをトリガーした場合に何が起こるべきかっていうことがそのWATの項目になります。
で、続いてWEARですね。
イベントハンドラーを配置するDOM要素の位置ですね。
これがいわゆるWEARになりますけど、さらに複雑なのはWATがAppStateとFWStateの上を閉じるクロージャーであることがっていうところがちょっと複雑であるというふうに言ってますね。
なるほどですね。
AppStateとそのFWState、フレームワークかなの略だと思いますけど、のStateですね。
アプリケーションとしてのStateとフレームワークとしてのStateっていう2つの概念があって、その上を閉じるクロージャーであるっていうのがまだちょっと悩ましいところだと言ってます。
これを一個一個説明していきますと、まずAppStateの方ですね。
いわゆるアプリケーションの状態、Stateのところですけども、AppStateっていうのはほとんどの人が状態として考えているもの。
普通にアプリケーションを使うユーザーが開発しても状態だというふうに認識するものですね。
AppStateがなければアプリケーションはユーザーに見せるべきダイナミックなものがありませんと言ってます。逆に言うとね。
もう一個FWStateですけども、フレームワークの内部状態のことを言いますと。
FWStateがなければフレームワークはどのDOMノードを更新すべきか、いつ更新すべきかを知ることはできませんと。
例としてはコンポーネントツリーやレンダー関数への参照などがありますと言ってます。
これらが複雑に絡めるのがまたちょっと悩ましいところだと言ってます。
続いていきまして、ではどのようにWattとWearを回復するのでしょうかというところですけど、
レンダリングされたコンポーネントをHTMLでダウンロードし実行することになります。
これがその効果だと言われている部分になります。
つまりHydrationはブラウザーでアプリコードを熱心に実行し、
AppStateとFWStateを回復するためのハックであり、そこの辺に関与しています。
その辺のことを一個一個説明が入ってますね。
4つぐらいありますけども、1つはコンポーネントコードをダウンロードします。
次にコンポーネントコードを実行します。
続いて何が、何がというのはAppStateとFWStateですけど、
何がどこでイベントハンドラークロージャーを取得するかを復元します。
最後ですね、Wattですね。イベントハンドラークロージャーですけど、
をWear、DOM要素にアタッチするというステップを踏んでいきます。
最初の3つのステップをリカバリフェーズと呼ぶことにしましょうと今回は言ってます。
12:04
コンポーネントコードをダウンロードして、コンポーネントコードを実行して、
何がどこでイベントハンドラークロージャーを取得するか復元するとこまでをリカバリフェーズと呼んでます。
最後、WattをWearにアタッチするというのが別のフェーズだということですね。
リカバリというのはフレームワークがアプリケーションを再構築しようとするときのことを言います。
アプリケーションのコードをダウンロードして実行する必要があるためリビルドにはやっぱりコストがかかります。
リカバリというのはハイドレートされるページの複雑さに正比例します。
複雑であればあればほど時間もかかるしコストもかかるということですね。
モバイルデバイスでは簡単に10秒かかることもあります。
リカバリというのは効果の部分なので、
ほとんどのアプリケーションは特にモバイルでは最適とは言えない起動性能を持ちます。
そりゃそうなんですよね。
スマホのスペックとかハードウェアの進化が行われたとしてもやっぱり限界はありますよね。
リカバリというのはオーバーヘッドでもあります。
サーバーサイドレンダリング、SSRまたは静的サイトの一部として
サーバーが既に収集した情報を再構築するのであります。
情報をクライアントに送信する代わりにその情報が破棄されました。
その結果クライアントはサーバーが既に持っている情報を再構築するために
効果のリカバリを実行しなければなりません。
もしサーバーが情報をシリアライズしてHTMLと一緒にクライアントに送信していれば
リカバリすることは避けられたはずです。
シリアル化された情報はクライアントがHTML内の全てのコンポーネントを
マネージにダウンロードして実行する手間を省くことができますと言っています。
そりゃそうなんですけど、HTMLとかDOMを全部持っておくと
それはそれでブラウザ側のコストがかかるし、ブラウザのメモリにも限界があるので
かつSPでブラウザ開いてたらどうすんだよって話はあるので
基本は避けるというか破棄しますよね、受け取った情報は。
言い換えればサーバーがSSR、SSGの一部として既に実行したコードを
クライアントで再実行することがハイドレーションを純粋なオーバーヘッドにしているんだよ
というふうな話をしています。
これすごくわかりやすいですね、この人の説明。
なるほどね。
続いて、続きの話としてはレジューム性ですね。
レジューマビリティというところです。
ハイドレーションに変わるオーバーヘッドを排除する方法というのが次の話ですね。
No Overhead Alternative to Hydrationというところに入っていきたいと思います。
オーバーヘッドを取り除くにはフレームワークというのはリカバリを避けるだけでなく
上記のステップ4ですね。すなわちワットをウェアにくっつける必要があります。
このコストを回避するためには3つのことが必要だというふうに言っています。
1つ目は、ワット、ウェア、アップステート、FWステートを含む
HTMLの一部としてシリアドされたすべての必要な情報というのを持っておくというのがまず1つです。
続いて2つ目です。
2つ目は特定のDOM要素ですべてのイベントを個別に登録する必要がないように
イベントバブリングに依存してすべての移動を傍受するグローバルイベントハンドルを作っちゃう。
15:05
これ結構力技な感がすごいですけど、確かにそれを個別に取る必要がないから、それはそうですよねって感じです。
しかもSPAなので一度レンダリングしたらその状態を持っているから、それは確かにそうなんですけど。
これまたすごいですね。今のが2つ目でした。
じゃあ3つ目ですね。
3つ目はイベントハンドラーです。
ワットを遅延的に回復させるファクトリー関数を作るというのが3つ目ですね。
なるほどですね。
遅延的にってところはミスですね。
ハフデリファンクション・ザ・キャン・レディ・リカバーって書いてますからね。
なるほどね。これができれば確かに少しは回避できるかなって感じですけど。
常期の設定というのはサーバーが既に行った作業をやり直すことなく、サーバーが去ったところから実行を再開することができるため、再開できますと。
ユーザーイベントへの応答としては、そのワットを遅延的に作成することで、ハイドレーションで起こるすべての不要な作業を回避することができます。
これらすべてはオーバーヘッドがないことを意味だとしますと言ってますけど。
正直に言うと現実的じゃないなとは思いましたね。
ただできることはできますよ、技術的にはって話ですね。
エンジニアが大嫌いな技術的にはできるというワードですね。
いわゆるできないよっていう意味がするんですけど。
翻訳が難しいところでございます。
余談でした。
続いてですね、メモリー優先時代のメモリ使用量の話です。
DOM要素っていうのは、その要素の有効期間中、イベントハンダラを保持します。
ハイドレーションはすべてのリスナーを熱心に作成するので、起動時にメモリーを確保する必要もありますと。
確かに、それは確かにそうですね。
それを作業するためのメモリー領域も必要ですよね。
一方で、リジューム可能なフレームワークっていうのは、イベントがトリガーされた後までイベントハンダラを作成しません。
そのため、ハイドレーションよりも少ないメモリーを消費することになりますと。
さらにイベントハンダラは実行後に解放されるメモリーも返却しますと。
ある意味、メモリーを回復することはハイドレーションの逆になります。
まるでフレームワークが特定のワットをダラダラとハイドレーションし、実行した後にディハイドレーションするようなものになりますと。
ハンダラの1回目の実行とN回目の実行の間にはあまり大きな違いはありませんと言ってますね。
この辺、大きな違いがないのであれば、普通にメモ化したくなっちゃう気もしますけど、それは結局メモリーを奪うことになるのであんまり変わらないですよね。
であれば、むしろメモリーを解放してディハイドレーションするようなものをやってしまったほうが、メモリーとしては確かに嬉しいような気はありますよ。
続いて、パフォーマンスの違いですね。
パフォーマンスディファレンスって書いてますけど、そこの観点に入っていきましょう。
この考えを実践するため、この考えっていうのは今の上のやつですね。
メモリーユーザージの観点の方ですけど。
私たちはリジウム性を軸に設計し、高速な起動を実現するためのフレームワーク、Quickっていうのを構築しました。
18:00
Quickっていうのはあれですね、ネットワーク系のお話ですね。
Quick.builder.ioのリンクも一応貼られてますので、そこももし興味ある人は見てみてください。
高速な起動を実現するためのフレームワーク、Quickではありますけども、
リジウムアビリティの効果を知っていただくためにクラウドフレアエッジ上で動作するというアプリのデモも作りました。
そのリンクも貼られてます。
Googleはクラウドフレアエッジ上で動作するデモアプリです。
Googleは、日本語おかしいですね。
Googleはクラウドフレアエッジを使ってるんですね。
今、ホットな話題のクラウドフレアエッジですけど、
ここの話はすでに何回かに分けて読んだことあるので、
もし興味ある方は過去の回聞いていただければいいなと思います。
かなりクラウドフレアエッジは熱い技術だなと僕も注目して、
やっと思い越し上げて勉強を始めました。
以上との通常アプリをデモを作りました。
このページでは約50マイクロ秒、MSでインタラクションが可能になります。
再開発戦略とQuickを使って、
私たちのウェブサイトであるbuilder.ioを作り直しました。
あ、そうなんや。
まさかの作り直したんですね。
Quickと私たちの他のソリューションですね。
パーティータウンとかそんなものがあるらしいですね。
パーティータウンっていうのは初めて聞きましたけど。
それらを使って私たちのサイトのJavaScriptの99%を削減し、
ページスピードスコアを100%を得ることができました。
あなたはまだ比較し、あなた自身のためのパフォーマンスの違いを体験するための
Hydrationを使ってフリーページを訪問することも一応できますよと言ってます。
The Old Page Using Hydrationっていう記事のリンクもありますので、
そこを見てもらってもいいですよということでした。
すごいですね。
ページスピードスコアの100分の100っていうのを達成するのはなかなかの話ですね。
へー。
でもその記事のリンクもありますね。
How we cut 99% JavaScript with Quick and PartyTownって書いてる記事のリンクがありますので、
ここも興味ある人は見てもらってもいいかもしれないですけど、
パーティータウン僕は本当に初めて知ったので、なんぞって書いてしまいました。
でもその辺を使うと、サイトのJavaScriptの99%削減することができたっていうのはかなりでかいですね。
やっぱブラウザーで遅くなる原因は、やっぱりJavaScriptの処理だったり、
バンドルサイズだったり、読み込みだったり、なんちゃらかんちゃらだったり、
やっぱりなんだかんだするので、そのJSを99%削れてるっていうのはかなりでかい話ですし、
言葉としてかなり抽象的ではあるので、
どういうふうなことをカットしたっていうふうなものに含めているのかっていうのは、
読まないとわかんないですね。
一応最後、ここまでの結論ですね。
コンクリューションの話をしようと思います。
簡単に言うと、ハイドレーションは作業を重複させるので、
結局オーバーヘッドになります。
サーバーっていうのはそのウェアとワットですね。
アップステートでFWステートっていうのを構築しますけど、
21:01
その情報をクライアントのためにシリアライズさせるのではなく、
破棄されます。
するとクライアントはアプリケーションを再構築するのに十分な情報を持たないため、
HTMLを受け取ることになります。
情報不足にもなりますので、
クライアントはアプリケーションを熱心にダウンロードし、
ウェアとワットを回復するためにそれを実行することを余儀なくされます。
別のアプローチとしては、リジムアビリティっていうのがあります。
再開可能性っていうのは全ての情報ですね。
ワットとウェアっていうのをサーバーからクライアントに転送することに重点を置いてます。
ユーザーとのやり取りだけで、
クライアントはその特定のやり取りを処理するためのコードをダウンロードしただけではなりません。
クライアントはサーバーの動作と重複しないので、
オーバーヘッドもありませんというふうに言ってます。
必要なのは最初のコードをダウンロードすることで、
それさえしてしまえばクライアントってのはサーバーの動作をもう一回重複することがないので、
オーバーヘッドすることもないっていうことですね。
というのでハイドレーションのワークアラウンドの面を解決しましたよというところでした。
なかなか面白いなと思いましたし、
でもリアクトの根幹の技術の一つにハイドレーションがあるはずなので、
この辺がカットできるのであればすごくいい話だなと思いました。
またデモアプリ、このbuilder.ioのデモアプリ、
サンプルを作ったと言いますけど、
そのデモアプリが何を使って作られているのか結構気になりますね。
そのJavaScriptだけで作ってるんだったらまた参考程度にしかならなくて、
ガチな実態としての話は微妙だなと思ったりはしますけどね。
あとはQuickを使っているのとパーティータウンがよくわからないので、
その辺を使ってどうなっているのか気になりますけどね。
というところでした。
一応QuickはNPMにも公開されていますので、
興味ある方はQuickをNPMからダウンロードして使ってみていただいてもいいと思います。
一応単純に始めるだけであれば、
npm init quick at latestというコマンドを叩けば、
一応デフォルトのテンプレートからスタートができるという風に言ってますので、
その辺を使ってもらっていいんじゃないかと思います。
一応Quickというもの自体のホームページにも来てるんですけど、
冒頭に書いてますね。
フレームワークリイマジンフォーザエッジと言ってますね。
ノーハイドレーションオートレイジーローディングエッジキャッシュラブル&ファンと書いてますね。
という新しいフレームワークを使った。
なるほど、これ自体がフレームワークなのか。
リアクトとか何とか作らないで新しく作ってしまったらしい。
Quickというフレームワークを。
そのQuickというフレームワークとパーティタウンとクラウドフレアエッジとかをわちゃわちゃやったら、
パフォーマンスがめちゃめちゃ上がったよという話ですね。
なるほど。
技術としてはそういうことを言ってますけど、
結局はハイドレーションにおけるオーバーヘッドを回避したというところが、
根本的なスピードアップにつながっているところだと思いますので、
参考程度にありましたけど、
これを僕らのプロジェクトにいきなり導入できるかってまた悩ましいし、
エッセンスだけ取り入れられるかっていうと、
それまた違う話だね、やっぱり聞こえましたね。
ただ、ハイドレーションを避けるっていうのか、
オーバーヘッドを避けることでパフォーマンスとかがだいぶ改善するなっていうのは
24:00
お話はすごく分かったのでいいなと思いました。
あくまでハイドレーションっていうのはワークアラートだったというところですよね。
どこは確かね、学びになったので今回の記事はすごくいいなと思いました。
大体9時半になってきたので、
今日の朝活動はこちらで以上にしたいかなと思います。
もちろん本日読んだ記事は後ほどツイッターでツイートさせていただきますので、
皆さんのほうでも読んでいただければいいと思いますし、
ここなんかうまいことリアクトとかビューとかで導入できるんだったら
ちょっと頑張ってみたいなっていう感はありますけどね。
誰かしらの記事を書いている気もしなくはないので、
ちょっと僕らのところでググってみようかなと思います。
というところで、では本日の朝活動は以上にしたいと思います。
今日もたくさん多くの方さんがいただきありがとうございました。
いつも通りダラダラ読んでしまったので参考になったかわからないですけど、
後ほどツイートしますので見てみてくださいってところです。
では本日水曜日中身ですね。
1週間の折り返しですけど、今日も一日頑張っていきましょう。
ではお疲れ様です。
