00:06
はい、9月1日、木曜日ですね。
遅刻朝9時を回りました。
本日から9月ということで、
9、10、11、12、3分の2が終わって、
残り3分の1がスタートですね。
学生の方では夏休みが終了して、
今日からまた授業、講義再開みたいな人も多いかなと
思いますけど、いかがでしょうかね。
はい、おはようございます。
munekeethこと河原です。
では本日も朝活を始めていきたいかなと思います。
僕もですね、1ヶ月の休休期間を終わりまして、
今日からまた仕事再開ということで、
社会人に戻らなきゃいけないんですけど、
なかなかちょっと頭を叩き起こさなきゃいけないのでね、
仕事、今日はパフォーマンス出ないかもしれないですけど、
はい、朝活はいつも通りやっていきたいかなと思います。
今日はですね、タイトルちょっと長かったんで、
カツ、カツアイじゃないわ、はしょってますけど、
1つ目の記事は
The impact of removing jQuery on our web performanceですね。
昨日読んだ、
How and why we removed jQuery from gov.ukですね。
続きの記事ですね。
これどれくらいパフォーマンスの改善だったのかというところ、
ここが気になったので読んでいこうと思いました。
もう1つがReading better,
retaining and applying what you readですね。
読書についての記事があったので、
これちょっと面白そうだなと思ったので、
読んでみようかなと思ってます。
では早速今日も記事に入っていきたいと思います。
校舎の方の記事はちょっと長いので、
もしかしたら今日読み切らんかもしれないですけど、
なので明日続けてみようかなと思います。
では入っていきましょう。
だいちさんとけんじさんですね。
おはようございます。
今日もご参加いただきありがとうございます。
では本文入っていきたいと思います。
最初はですね、
Image data versus and compressed dataですね。
画像データと圧縮データの比較ですよということですね。
前述したようにJQueryライブラリーというのは
32KBの圧縮および最小化、
コードから空白とかを取り除いて
繰り返しの単語を置き換えたものですね。
とかを最小化されたJavaScriptだけでしたと。
何MBにもなる画像に比べれば
大したデータではないように思われるかもしれません。
しかしこれが全てのページに存在するとなると
ウェブパフォーマンスの観点から
かなりのデータ量に相当することになりますと。
昨日見た感じだと
確かJavaScriptが動いているページ数が
200以上って言ってたので
それの何パーセントがJQueryで作られているか
わかんないですけど
多分結構大多数だと思うので
結構バカにならないですよねと思いましたね。
また画像データと圧縮されたJavaScriptのデータには
大きな違いがあることも特筆すべき点です。
ブラウザとデバイスは
この2つのデータタイプを非常に異なる方法で処理します。
JavaScriptはレンダーブロッキング、
リソースとして知られています。
つまりブラウザがJavaScriptと出会ったときに
ダウンロードされ圧縮が解除され
最終的に解析され実行されるという
多段階のプロセスを経ることになります。
03:01
これはすべてデバイスが利用可能な
中央処理装置、CPUとメモリ内で行われます。
これらのタスクはデバイスや接続によっては
非常に時間がかかり
エネルギーを消費する場合があります。
この辺は皆さんも基地の通りだと思いますね。
残念ながらこの間JavaScriptの実行が完了するまで
デバイスの画面への実際のピクセル描画は
一切停止されなければなりません。
だからブロッキングということですね。
完了するとブラウザページの残りの部分を
ピクセルで描き続けることができます。
画像や画像データはレンダーブロッキングしないので
追加の画像データを並行してダウンロードしながら
ウェブページの一部を描画することができます。
したがって32KBの画像は
32KBの圧縮されたJavaScriptよりも
パフォーマンス影響がはるかに少ないのです。
これはその通りですね。
32KBの画像は画質が低いかもしれないので
サイズを小さくしなければいけないという
あるでしょうけど、サイズとかデータ量の観点からいくと
JSよりも画像の方が実は強いよねという話ですね。
このことは一般に速度が遅く
古くて安価な低スペック端末のユーザーには
特に当てはまってしまいます。
このブログの記事の残りの部分では
これらのユーザーに焦点を当てますと言っています。
本当にこれ中の人が書いているとしか思えない。
中の人というか同業の人が書いているとしか
思えないですね。
政府関係者にここまでの専門家がいるのか
イギリスは分からないですけど
少なくともちゃんとウェブ開発者の人が
このブログを書いているとしか思えないような
文面だなと思いました。
中身をよく知っているなという感じですね。
めちゃめちゃ上からで申し訳ないですけどね。
いきましょう続いて。
最初ですね。
HELPING USERS WITH LOW SPECIFICATION DEVICES
さっそく指定された通りですけど
低スペック端末のユーザーを支援しましょうと。
低スペックのデバイスとは
古いノートパソコンやタブレット
また額安分割レデバイスですね。
多くの場合限られたデータプランの
アンドロイドデバイスであると考えられます。
海外はアンドロイドが多いですからね。
これらのユーザーは最も遅いデバイスを
使用しているため
GOV.UKへのアクセスができるだけ早く
効率的で安価になるようにするために
最も支援が必要になります。
昨年10月
オフコムというところが
200万世帯が固定ブロードバンド
およびスマートフォンのいずれかに
料金的な問題を経験している
というふうに推定しています。
ちなみにまたこれについても
記事のリンクがわざわざちゃんと載っていて
今見えないでしょうけど
僕の画面にはちゃんと
グラフまで載っていますね。
なのでこの辺結構見てみたい方は
後ほど記事から追ってください。
2022年5月における
GOV.UKの
リアルユーザーモニタリングのデータから
ロード時間分布のグラフの
画像というのを貼っています。
劣等者比の
75%のロード時間が
0.824秒で
一部のユーザーには2.35秒という
06:00
大きなロード時間がかかっていることがわかっています。
ほんとにネットワーク帯域とか
パフォーマンスが低い
端末を使われている
という方だと思いますね。
この時点で当社は
ユーザーのデバイスから収集した
特命のリアルユーザーモニタリング
RUMのデータから
GOV.UKがすでに非常に高速なウェブサイトである
ということは明らかになっています。
そこは特筆にすべきだなという点ではあります。
大半のユーザーにとって
サイトの読み込みはもちろん1秒未満になりますが
分布グラフの上の図を見てみますと
ページのロード時間が
最大2.35秒になるユーザーもいる
ということがわかっています。
これらのユーザーのRUMパフォーマンスのデータを
さらに詳しく調べると次のようになります。
ユーザーの
75%はイギリスに住んでいます。
ユーザーの35%はAndroid端末を
使っています。ユーザーの画面に
最初のページピクセルが表示されるまで
約2秒かかっていると。
これはレンダリング開始の指標と
言われています。
上記の統計から
Androidユーザーの多くは
CPU速度やメモリー容量に
制限のある低スペックの端末を
使っている可能性が高いと推測されます。
その前提で32KBの
圧縮JavaScriptを削除するとパフォーマンスに
どのような影響があるのかというのが次のアプローチ
だったということですね。
少なくともイギリスの
政府サイトの
統計データによると
そんな感じらしいですね。
75%はイギリスに住んでいて残り25%の人が
それでもイギリスの公式サイト
ホームページにアクセスをしていると。
また旅行者とかなんか
いらっしゃる気はしますけど
ただ一部のユーザーで
ページのロード時間が
最大2秒以上かかるのは結構遅いので
確かにそういうユーザーまで
全部加味して
JavaScriptのパフォーマンスを考えると
まあまあという感じはありますね。
続いていきましょう。
どういうアプローチを取っていたか
ということですけど
最初はテスティング・ザ・インパクトですね。
インパクトのテストですね。
ここで私たちの
パフォーマンステストというのが非常に役立ちます。
ラボベースパフォーマンステスト
ということを
イギリスのサイト開発者の
人たちは使ったそうですね。
私たちは毎日
特定のシミュレーション機器と
接続速度を用いて
gob.ukのページでテストを実施しています。
こうしたテストを毎日繰り返すことで
gob.ukを訪れる実際のユーザーに対して
私たちが行っているサイトへの変更が
どのような影響を与えるかというのを
モニターすることができます。
gob.ukのデバイスと
2Gのモバイル接続で
ユーニバーサルクレジットの
開始ページを訪れた
ユーザーのシミュレーションでは
グラフはjQueryの変更が行われた場所を
はっきりと確認することができますよと言っています。
2Gって久しぶりに聞いたけどな。
でもまだあるんですね。
2Gのところが。
本当に定位期待ですね。
さっき言った
ユニバーサルクレジットのページですね。
なぜこのユニバーサルクレジットのページで
分析データによると
gob.ukで最も訪問者の多いページであるため
09:00
どのようなデバイスや接続を
使用していたとしても全てのユーザーにとって
素早く読み込まれることが重要であるためだと
言っています。
記事内には画像があるんですけど
上のグラフが
示すようにページが画面にピクセルを
完全に描画するのに
かかる時間ですね。視覚的に完全
ってことですけど。
11.3秒から約9.4秒に減少しましたと。
17%改善をしたよ
ということですね。
外すだけで。
また視覚的な完成度の向上だけでなく
ページのロード時間の改善も
明確に見られましたと。
さらに下にグラフがあるんですけど
グラフからは
ページが完全に読み込まれるまでの時間が
20.42秒から
18.7秒ごみに短縮され
8%を改善しましたと。ページの総ロード時間が
19秒から
17秒ちょいに短縮されたことを示しています。
全体的には9%改善したよ
ということですね。
有定
20秒とか今日かかりすぎな気はしますけど
どんだけかかってる
って感じですけど。
そもそもユーザーの端末スペックと
ネットワークのあれが
低いのでしょうがないと思いますけど
とはいえ20秒もかかるのはさすがに
ストレス半端ないでしょうね。
これはユーザーが
より早くページとインタラクトできるようになった
ことを意味します。
インタラクト性能の指標というのは
最初にページと対話できるタイミングを示すもので
ユーザーにとっては重要です。
ページとインタラクトできるということは
そのページがまだ機能しているという確信を
ユーザーにも与えます。
さらにもう一個データのグラフがあるんですけど
下のグラフというのはインタラクティブになるまでの
時間が11.34秒から
9.4秒に短縮されて
デバイスの最初のCPUアイドルが
11.32秒から
9.42秒に短縮されたことを示しています。
結果的には17%
の改善ですよということですね。
レンダリング観点では9%ではなかったんですけど
結局インタラクティブにユーザーが
触れるという観点でいくと17%の
速度改善になったというので
これは結構大きいですね。
ブロッキングされる時間では
かなり短縮されていることに
変わりはないので。
とはいえでもまだ9秒というところは
なかなか課題ではあるんですけど
そこはユーザー端末の指標があるのです。
難しいですね。
とはいえでもJQueryを
ひっぺかすだけでそんな改善をする
ということは逆に言うとJQueryって
そういうぐらいブロックするものがあるのだ
というところがあるかなと思いました。
僕がもう1個気になるのはJQuery Slim.jsだったら
どれくらいパフォーマンスが変わったのか
という気もしなくはないですけど
今のUKのサイトは
JQuery全部ひっぺかしたらしいので
それはそれで素晴らしいなと思います。
最後に
improving.gov.uk for everyoneですね。
gov.ukはみんなのために改善しますと言っています。
ウェブパフォーマンスの向上というのは
多くの場合時間をかけた
ブロックの小さな全身的な変更で
構成されます。
ですからより広いウェブパフォーマンス
コミュニティからこの変更に対するサポートが
得られたというのがなかなか素晴らしいことですよ
と言っています。
さらに今言ったより広いウェブパフォーマンス
コミュニティというところに
12:00
リンクが貼られていますね。
リンクは
web.dev.gov.uk.drops.jquery
というリンクが
貼られていますので興味ある人は見てみてください。
上記のパフォーマンス
リンクの結果から分かるように
gov.ukはすでに大多数のユーザーにとって
非常に高速なウェブサイトですが
低スペック端末や低接続
低速接続で苦労している
多くのユーザーのページ
パフォーマンスを改善することもできました。
高速なデバイスと高速なブロードバンド
接続を備えた今日のモダンな
ウェブでは32キロバイトのJavaScript
は大したことないように聞こえるかもしれません。
しかしある種のユーザーにとっては
gov.ukの体験に大きな
違いをもたらすのですというところで
お話をさせていただきます。
昨日も読んだのですが
イギリスの公式のサイトで
それだけ低接続の
数字としてはかなり少ない
パーセントですよね。
その人たちに対して
しっかり対応しなきゃ
パフォーマンスを改善しなきゃいけないよね
という意識をして
200以上のページから
JQueryを引っかかったという
このアプローチはなかなかすごいなと思います。
お金を生むような
動きではないし
むしろ失うことが多いと思いますけれども
これをやり切った、しかもちゃんと成功している
というのが素晴らしいなと改めて感じますね。
ということで
一旦一つ目の記事
It's the impact of removing jQuery on our web
パフォーマンスという記事は終了。
もう一個の記事ですね。
Reading betterで
Retaining and applying virtuallyですね。
読書系の記事について
入っていきたいかなと思います。
じゃあいきましょう。
この記事では
読書を最大限に活用する方法について
解説してみましょう。
本でも論文でも学術論文でも構いません。
やめること、読書のレベル、名著の選び方
読解力と記憶力の向上
効果的なノートの取り方などなど
取り上げています。
やめることですね。
やめ方は確かに、この本読むのやめた方がいいみたいな
観点は結構僕持ってないかもしれないので
それは大事かもしれないですね。
読書の利点の一つは
他の人がすでに解明していることの
必要な部分をマスターすることができるということですね。
これは読んだ本から得た教訓や
洞察を記憶し応用することができる
場合にのみ当てはまります。
私のこれまでの人生の中で
広い分野にわたっていつも本を読んでいない
賢者を私は知りません。
逆に言うと賢者はだいたい本を読んでいるということですね。
チャーリーマンガー
という方がそういうことをおっしゃっています。
それでは私たちが最も役立つと感じた
テスト済みの洞察を探ってみましょう。
ここです。
ちょっと読書の習慣の話になると
CTO協会に
僕は参加していて
結構いろんな人と喋ったんですけど
やっぱりCTOの方もそうですし
いろんな経営者、CEOの方もそうですけど
みんな本を読んでいますね。
読んでいない人はたぶん一人もいなかった気がしますね。
必ず1週間の中でも
絶対にこの時間は本を読むみたいな
毎日この時間は本を読む
読書の時間にちゃんと終わっていますよ
というふうに皆さんおっしゃっていたので
本を継続的に読むということが
もう習慣になっているんですよね。
15:00
そこは結構大きいなというか
反省だなと思いました。
僕は読む人は読まないかたまにあったりするので
やっぱりちゃんと習慣として読むのが大事だなと思いましたね。
かつ
CTOの方まで行くと
技術的なものよりやっぱり組織的なこととか
チームビルディングみたいな話も結構読まれるんですけど
とはいえ技術のキャッチアップも
必ずやっていますね。
数学とこんな技術が今出ているんだとか
これ何ができるのとか
これができないことなんだろうみたいなところまで行く。
やっている人はさらに
そこから軽く手を動かしてみて
こういうふうに使うんだよみたいなところまでやっていますけど
本当に皆さんそういうことやっていて
すごいなと思いました。
お忙しい中やっぱり
勉強と技術のキャッチアップを怠っていないというところがあります。
余談でした。
じゃあ早速入っていきましょう。
最初のセクションは
クイットブックスなのでいきなり
本を読めるというところからですね。
良い本はほとんど自分で読めます。
悪い本は苦痛でしかないというところから
入っていますね。
瞬時にそれを感じます。
よく書かれていてアイディアや洞察が詰まっているだけでなく
よく整理もされています。
流れがいい。
次のページが読みたくなる。
本はすぐに読み始め
すぐに諦めると言っています。
読み始めた本を
最後まで読みたいという欲求は
時として私たちに逆効果になることがあります。
良い本は勝手に読み終えてくれる。
あなたはその本を手放すことができません。
一方悪い本を
読み終えようとするのは
满載した一輪車で泥の中を歩くようなものです。
毎回海外の方の
表現の仕方は
本当に面白いなと思います。
続いて
たくさんの本に目を通す
数冊を読むすぐにベストのものを
2回読み直す
読書に関しては
始めたものを最後まで読む必要はない。
悪い本あるいは何でも読むことを
罪悪感なしにやめることが
できるとわかれば結構
いろんなものが変わります。
たくさんの本に時間を取られていても
素晴らしい本を読むことはできません。
たくさんの本に目を通すとすぐに
良いものを2回読みます。
この言葉は
本当に大切だから2回言ったんですね。
というところでした。
よくある読書の格言に
本に読まれるという言葉がありますよね。
それは
夢中になってしまうとか
気づいたら読み終わってしまったというのは
僕はちょっと違うかなと思っていて
最初そう思っていたんですけど
読むことを義務化してしまうという
観点になっているとき
本に読まれているなという感じですよね。
それをやめるようになったら
やめたほうがいいなと思いますし
別に全部を読む必要はないですからね。
うちの代表も言っていますけど
本の中で大事なことでだいたい2割ぐらいしかないよ
と言っているのでそこだけピックアップで
読めれば別にいいなという感じですね。
まず最初
本をやめるというところでした。
続いて
長いな。
続いては
レベルズオブリーディングですね。
読書のレベルって言っていますね。
はい。
いきましょう。
ページまたは画面上の文字を読むこと
18:00
というのは結構簡単なことです。
私たちは小学校でこの方法を学びました。
問題はこれが私たちが読むことを
学んだ唯一の方法であるということです。
あー確かにね。
言われてみればそうかもしれない。
読むものによって読み方を変えることはより理にかなっています。
全ての本を同じ強度で
読む必要はありません。
ざっと読むに値する本もあれば
全神経を集中させるべき本もあります。
どの程度の労力をかけるかは
何を読むかなぜ読むかに
結構関係しますねと言っています。
リーディングレベルですね。
リーディングレベルですけど
読書に対する4つの異なるアプローチを
提供しています。
最も簡単なものから最も難しいものまで提供しています。
ほとんどの時間は
レベル2と3の間に費やされますよと言っています。
ちなみにリーディングレベルですけど
別で記事のリンクが
貼られているので
後ほどこれもツイートするので
興味ある方は見てみてください。
How to read a bookという本の読み方についての
記事が別で
貼られていますね。
では行きましょう。
まず1つはレベル1ですけど
レベル1は
Reading to entertainですね。
小括弧で習う読書のレベルだと。
レベル2は
Reading to informationですね。
表層的な読み方、ざっと読んで
どんどん読み進めて本の雰囲気をつかんで
要点をつかみましょうと。
3つ目ですけど
Reading to understandですね。
読書における真の主力というか
メインですね。
じっくりと読み込んでいく読書というのがこれだと言っています。
ラスト、Reading to masterですね。
あるテーマについて
一冊の本を読んだだけでは
自分の知識に多くの盲点がある可能性があります。
同じテーマについてさまざまな本や記事を読み
矛盾点を見つけ評価し
意見を述べるのがシノプスリーティングだと。
シノプシスリーティングですね。
失礼しました。
シノプシス、脳神経の話に結構似てるやつですね。
読むのは結構大変な労力が
必要になりますけども
その労力をどこに費やすかによって
最高のリーダーを得ることができるんです
と一応締められていますね。
やっぱりそうですね。
レベルでいくとやっぱり
インフォメーションとアンダスタンディング
あたりだと読みますね。
ガンガン乱読ですかね。
多読とか乱読をする
レベル2の読み方か
しっかり読むというところですね。
レベル3のところですね。
じっくり読み込んでいくというところ。
この辺がやっぱり時間を取られるのは確かにそうかもしれないですね。
レベル4までいくと
もはや読書というか
研究に近い感じはありますけど
そこまでいける人はさらに
深みまでいけるんだなという感じがしますね。
今のが
続いてスピードリーディングですね。
読書速度です。
読書スピードというのは
虚栄心の強い詩評ですと
もうバッサリ言ってますね。
あなたがどれだけ早く読んだか
昨年何冊読んだかなんて誰も気にしてませんし
現実の世界では何を吸収し
何に応用するかが重要なのですと。
読む価値のあるものを見つけるために
広く目を通す。そしてゆっくりと深く読み込む。
シンプルだが簡単なことではないですよね。
21:01
というふうに言ってます。
これもやっぱり思います。
何だっけ。
速読ですけど
僕は一応速読を勉強したことはあったんですけど
僕はできなかったんですね。
あまり相性悪かったというのもあるんですけど。
理解はできるし
頭には入るけど
それをちゃんとインストールできたかというと
結構疑問な感があって
難しいなと思いますね。
人によって全然できてると思うんですけど
読むことが目的になっちゃう人もいらっしゃったりするので
なんか微妙だなと思いました。
あと誰かがおっしゃってたんですけど
僕この格言好きで
例えば本を千冊とか
自分が時間の許す限り読み切ったとしましょう。
その時に残っているものが
知識だというふうに言っているので
結局はそこが重要なんですよね。
三冊読んで三冊分の知識が
全部まるって入るのと
千冊読んで結局三冊分しか
入らない人もいたりするので
どっちにしろアプローチとして一緒ですよねということなので
何が自分の中に残ったかということが
大事だよということをやってました。
さらに
弁護士の方とか
めちゃめちゃ読書してるんですけど
いろんな社会の事例だったりとか
事象に対していろんな事件が起きるので
それに対して弁護をしなきゃいけないから
とにかく知識量が大事らしいんですけど
弁護士の人って本当に1日に3、4冊平然と本を読むんですよね。
人によっては
年間万の単位で
いくくらい本を読むらしくてですね。
本当そういう人たちと比べると
読書スピードなんて高かしれてるなという感じはしました。
それよりはやっぱり
何を得るかというところが重要ですよね。
読み方はやっぱりあるので
全部読み切れなくてもいいというさっきの話と
いろんなことを加味して
自分の中で一番学習ができる読み方というのを
探していくのが結構大事かなと思います。
これは勉強方法にちょっと近い感じがありますけど。
では続いていきましょう。
続いてはチューズグレイトブックスなので
優れた本を選びましょうというところですね。
読書から得られるものを
向上させるには
優れた素材を選ぶところから始まります。
家の中がガラクタだらけだと
健康的な選択ができないと同じで
分かっていない本からは優れた知見を得ることは
なかなかできないかもしれないですねと言っています。
多くの人がそうであるように
あなたも自然と新しい本に惹かれることでしょう。
新しい本には
色気だったりマーケティングだったり
そして砂糖でコーティングされた嘘が
溢れていると。
砂糖で溢れたコーヒー
飲みたいかというとちょっとあれですけどね。
一部の新刊本は価値があるかもしれないが
大半は数ヶ月で忘れ去られるでしょう。
時間が読む価値のある本と
ざっと読むか無視すべき本か
選別してくれます。
もしどの新刊書が素晴らしく
どの新刊書がそうでないかと見分けることが
できないのであれば時間が解決してくれますし
時間がその本を選別してくれますと。
時間が有効なものと
そうでないものを選別してくれるので
長続きしない本に
時間を浪費する必要はないよという
忘れられたような本題があれば
ざっと読むだけでいいよということですね。
新しい本で必要なものスキルアップだったり
レシピだったり例えばプログラミング言語だったり
というのはほとんどオンラインで見つけることが
できます。
これは耳の痛いことは
かつプログラミング
24:00
関係に関する書籍って
やっぱり
ライブラリーとか言語が出てから書籍が
出るまでってめちゃめちゃラグがあるんですよね。
書き終わったとしても
そこから出版社の構成
やったり何やらがあってやっと
実際に本が出ましたので
ほんまに時間がかかるんですよ。さらに
出版業界のあるあるなんですけど
物理本より
デジタル本のほうが時間がかかるんですよ。
これは実は。だから物理本のほうが
みんな早いし人件費も安いんですよ。
もちろん紙代はかかるかもしれないと
みんな思うかもしれないですけど
人件費がやっぱ高いらしいです。なので
ラグがあるんでそういう系はやっぱり
オンラインで公式サイトから学ぶほうが
いいかもしれないですね。
ちょっと余談でした。
読書時間ってのはやっぱり限られていて
時の試練に耐える知識に向けられるべき
ですと言ってます。新しいものを読む機械
損失っていうのは今まで読んだ最古の本を
再読することになります。
古い本を読め、最古のものを2度読む
この方法は誰もが話題にしている
最新のベストセラーを読むよりも
色気がないように思えますが
そうした本の大半は時間の試練に
耐えられなくなるものだという風に言ってます。
結局名著って言われるものを
読みましょうと。名著っていうのは
時間が選定してくれるので
そこを引いてくださいってことでした。
というわけで
30分になったんですけど記事の
残りをザーッと今見てるんですが
残り
多分10分じゃ終わんない
気がしてるので
すみません。これは明日に続けようと思います。
読書についての記事ですね。
というわけで
今日の朝活はこちらで
区切らせていただきたいかなと思っております。
今日もご参加いただいた多くの方
大変にありがとうございました。
また明日もゆるっと参加いただければなと思います。
また今日から9月1日ですね。
月が始めていることで
気持ち切り替えてまた皆さんも
頑張っていきたいなと思いますし
僕も社会人復帰するので
なんとか頭叩き起こして頑張っていきたいなと思います。
では終了します。お疲れ様でした。
