00:06
9月8日、木曜日。時刻は朝9時を回りました。
今日の天気はちょっとまだ曇ってますね。
というよりも、昨日の夜、Appleのイベントがあったので、皆さん寝不足なのかもしれないし、
今日は朝起きてないかもしれないですね。
はい、おはようございます。ひめめめのきーすくんとくわはらです。
では本日も朝、雑談を始めていきたいかなと思います。
先ほど話したAppleニュースですけど、イベントですけど、僕は見てなかったので、
今からダーッといろんな記事を見て、
Appleの更新というか、どんな発表があったのか見ようかなと思います。
僕は毎回、Gizmodeというサイトがあって、そこから情報を得ることが多いので、
そこの辺を眺めてみようかなと思います。
たぶんまとめがあるはずなので、というところですね。
はい。
なんかいろんな情報が、Twitterザーッと眺めた感じで出てたので、
見るの楽しみだなと思ってます。はい。
ではでは、早速今日も入っていきましょう。
久しぶりにWeeklyのトロンテのニュースを眺めてなかった感じですね。
ちょっと最近眺めてなかったので、改めて眺めようかと思います。
今日は第375回目ですけども、
375回目は実は、前回、いつでしょうね。だいぶ前ですけど一度読んではいるので、
その中から今度は別のものを読んでいこうかなと思います。はい。
改めてですけど、10個読んでいこうかなと思いますね。
1つ目はまずReading Betterです。
より良い読書のためのヒントで、
こちらについてはこの朝かつても取り上げているような改めて読ませていただいたという感じがありますね。
2つ目にThe History of User Interface、UIの歴史ですね。
1973年から2007年までのUIの歴史というのをまとめていて、
1973年は後のデスクトップメタファーとして使われによったZeroX Oldというようなワークセッションについて取り上げて、
2007年ではSnow LeopardのUIについて取り上げていますよということでした。
3つ目はFluid Sizing Instead of Multiple Media Queriesですね。
メディアクエリなしでフルイドサイジングというのはどうやって再現するんですか?
その実現方法というのを書いています。
クランプというメソッドがあって、それを使用することでメディアクエリを使用せずに、
ビューポートに応じたバリューを適用することができます。
この記事では数学を活用して複雑な条件分岐をクランプで実現する方法について考察をしています。
CSSのチップス的なお話っぽいので、これはこれで。
実装のレベルとしての話は結構面白そうだなと思いました。
続いて4つ目ですね。
次はWhy We Traditioned from Sprints to Basecamp Shapeup Methodologyというところですね。
すみません、英語をたどたどで。
アジャイルの手法に問題点を感じ、シェアアップの手法に切り替えた事例というのを紹介しますと。
アジャイルの手法のときの問題点はシェアアップか、どのように解決したかについて解説をしていますというところでした。
03:00
シェアアップという方法を全然僕は知らなかったので、すごく気になりますね。
アジャイルはですね、どういうところに当てはまるかとかどういう課題を解決するかってちゃんと理解してないと、
アジャイルをやってしまっては意味がないのでね。
その辺が何かあるんじゃないかって気はしてます。
続いて5つ目ですね。
The Funnel Technique in Qualitative User Researchですね。
ユーザーインタビューにおけるファイル手法についての解説です。
この手法では幅広い自由回答式の質問を行ってから、
より範囲が狭い自由回答式の質問やクローズドが質問するようにしていくと。
これによってそのバイアスを排除し重要なデータを見逃すことを防ぐことができますよということを言っています。
ファネル手法って僕全然知らなかったんですけど、そういうのがあるんですね。
残り5つの記事はインブリーフという感じですね。
じゃあ6つ目の記事ですけど。
How to Use Firefox for Accessibility Testingですね。
The A11y Projectというところです。
Firefoxの優れたアクセシビリティ観測の機能について紹介していこうというところです。
続いて7つ目ですね。
7つ目はUXUI Chips A Guide to Search Inputsですね。
最高の検索入力ボックスをデザインするためのガイドだというところです。
こういうアトムスレベルのコンポーネントのお話って何やかんや拡張したりとか、
他にも転用できたりするので割と気になりますね。
続いてReinventing Adobe Spectrum Colorsですね。
これ8つ目ですけど。
Adobeのスペクトラムズカラーシステムバージョン6について、
それがどのように進化したかというのを解説していきますということでした。
ちょっとAdobeについて僕は全然追ってないのでごめんなさい。
これは今回は端折ろうというか読まないようにしようと思います。
続いて9つ目ですね。
テスティングフィロソフィーです。
自動テストがどうあるべきかについての考えを記事にまとめていますよということでした。
ラスト10個目ですね。
Testable Frontend The Good, The Bad, and The Fluckyというタイトルですね。
フロントエンドのテストについて特定のプロセスやツールではなく、
アーキテクチャを重要視することが重要であることを説明していますよということでした。
今ので10個目です。
今回もちょっと10個バーッと見ましたけど、
やっぱり気になる記事だらけだったのでどうしようか悩ましいですね。
さっきのアジャイル手法のところ、
アジャイルという手法に疑問を持ちてシェアアップに切り替えたというのもすごく気になりますし、
ヒストリーユーザーインターフェースも気になりますね。
1973年から2007年のSnow LeopardのUIのところまでを
ざーっと並べて語られているという感じですね。
ちなみにこれ、やっぱり画像がかなり多くてですね。
06:00
一応どんなUIの歴史だったかというのをガッと軽くだけで触れていますね。
あるんですけど、ただやっぱり画像で実物を見ないと
多分ふーんという感じになる気がするんで、
まあ喋ってもいいんですけどちょっと、
しかも内容もかなりテキストだけにすると内容は結構短いので、
これちょっと皆さんの方で見ていただく方が多分面白いかもしれないですね。
僕は僕でこれ気になるので読みたいと思います。
はい。続いてそのファネルテクニックってやつですね。
ファネルテクニックをざっと見てるんですけど、
割と画像を使った解説がかなり多くですね。
これもちょっと語ったところでどうなんだろうという気はしますが、
まあでも学びはありそうだなという感じはしますね。
が、まあちょっと一旦、今日は読むかわかんないですね。
最優先で読むかはちょっと悩ましいので一旦割愛します。
あとはUXUIチップスのインプットフォームですね。
UI UXについてのチップスの話です。
やっぱりこれはソースコードと画像がちょっと多めって感じですかね。
あ、ごめんなさい。ソースコードはなかったですけど画像がちょっと多めなんで、
テキストだけを音読してもちょっとイメージできないかもしれないですね。
というところで気になったのはやっぱチェスティングフィロソフィーってやつと、
さっきのアジャイルじゃなくてシェアアップっていう手法のところですね。
が気になったのでそこを読んでいきたいと思いますが、
あとなんだっけ。
もう一個テストの観点ですね。
テスタブルフロントエンドってですね。
ザグッド、ザバッド、アンドザフラッキーってやつですね。
フラッキー?フラッキーですね。
っていうところを読みたいですけど、
これもちょっと長そうなんで今回は割愛してたぶん次回読んでいこうかと思いますね。
というわけで今日読むのは、
アーティスティングフィロソフィーとさっき言った
シェアアップっていうメソドロジーですね。
を読んでいこうと思います。
ただまぁ後者の方もちょっと記事長いので
ちょっとこれ今日で終わりきらない気がするので
また次回、明日に回そうかなと思ってますので。
そんな感じでいきたいと思います。
ではではいきましょう。
アーティスティングフィロソフィーというところです。
じゃあまず翻訳をかけていきたいので少々お待ちください。
アップルのイベントがあった次の日は皆さんクレジットガードの消費が激しいというのを聞いたりしますけどどうなんですかね。
もうすでに昨日の夜のうちにガンと予約したりしちゃったんですよね。
でもまだ日本に来てないものもたくさんあると思うのでどうなんだろう気はしますけど。
とりあえず社内のスラックだったりツイッターだったりを眺めようかなと思いますけど。
じゃあいきましょう。
テスティングフィロソフィーです。
だいたい5分くらいの記事だそうですね。
これまでソフトウェア開発についてはいろいろと書いてきましたが
テストに関してはやっぱり沈黙を守ってきました。
品質保証っていうのは私の得意分野ではないし
過去に一緒に仕事をしたエンジニアの何人かはそれを確認できるだろうというところです。
特にアーリーステージのスタートアップ企業で働いたり
09:00
コンサルティングの仕事をしていた頃とはテストを完全にやっぱり軽視をしていたと。
QAエンジニアが捉えどころのない問題をキャッチしてくれるのを頼りに
より複雑なケースに対していくつかのユニットテスト確保で私は平成を保っていましたと。
その後、私は異なる哲学・フィロソフィーを受け入れる企業で働き始めました。
QAというのは開発プロセスの通常の一部であり
本番環境へのバグの出荷から私たちを守ってくれる専任の担当者というのは言いませんでした。
私たちは自分たちでテストを書き、お互いの仕事を検証しなければなりませんでした。
その結果、自主性を重んじると同時に責任も重くなることが分かりました。
大企業ではあなたが書いたソフトウェアが何年も運用される可能性があります。
良いテストスイートがあればぐっすり眠れるようになりますよというところです。
それを具体的に入っていこうということでした。
まず最初はユニット&インテグレーションテストです。
ご用意のお名前だと思いますが、単体テストと結合テストです。
テストには一般的に2つの考え方があります。
1つはユニットテストを支持し、もう1つはインテグレーションテストを支持するものです。
どちらの考え方にも長所がありますが、健全なテストスイートは両方を持っています。
それはそうですよね。
片方だけでやるというのは健全ではないし、テストをやるというのはそもそもフィロソフィーではない気がしますね。
もし私がプロトタイプや定品化されていないものに取り組んでいるのであれば、
テストを書くのを完全にスキップしてしまうでしょう。
これもわかりますね。
プロトタイプだったりするとか、POC的なプロジェクトだったりすると、
そんなテストをすることでもちゃんと動作することを、
いかにコストを下げてかつ早く動くようなものを作れるかというのが重要だったりするので、
テストは後回しにすることが結構多いと思いますね。
バグだバグだと言われたって、これプロトタイプだしだという話になるのでね。
また、要件が頻繁に変更される可能性も出てあるので、やっぱりテストが進化を発揮できないからです。
テストというのはそもそも決まったということを前提に、
それを確認する作業になるので、そもそも決まっていないのであれば、
それはテストをそもそもやる意味はないですよね。
しかし他の全てのケースでは、アプリケーションの重要な公開機能のための
E2Eテストとドメイン固有のロジックをカバーするユニットテストというのを
用意することをお勧めしています。
E2Eテストという、いわゆるエンドとエンドテストですね。
認証や支払いのような最も重要なシナリオが機体通りに動作するということを保証します。
一方ユニットテストというのはその細かな部分をカバーします。
特にユニットテストではビジネスロジックに重点を置くことになるでしょう。
しかしアプリケーションがロードされ、ビジネスロジックが適切な結果を生成することを検証できる限り、
本番環境に入り込むバグの深刻さを軽減することはできますねということでした。
12:00
ビジネスロジックというのはユニットテストのほうで担保、カバーするというのが多いと思いますね。
結果的に言うと要は両方必要だよねという話は全然ありますし、
どっちにどれぐらいの比率とか重みを付けようするとか、
プロジェクトの予算観であったりとか、クオリティーの求める質であったりとか、
時間ですよね、納期がいつまでするかによってユニットテストの案は割り、
インテリジェントテストの案は割りとなったりしますけどね。
ちょっと余談になりますけども、もしそのテストのことをちゃんと考えるんだったら、
なんだっけ、テスティングピラミッドだっけ、
なんかそういう名前の何かがあったはずですね。
そのピラミッド、トロフィーかな、テスティングトロフィーだったっけ、
そういうのをテストについて言及されたサイトだったり、
そういうのを検証するようなページがあるんですけど、
ピラミッドだった気がしますね。
それに行くとユニットテストがテスト全体の7割を占めますと。
インテグレーションテストが2割で、
あとそのシステムテストはE2Eテストが1割というような比率になるのが健全だというのが
そのサイトでおっしゃってましたね。
やっぱりユニットテストが7割というところで、そこでやる。
つまりビジネスロジックをしっかり確認するところで、
大体あの品質っていうのは担保できるよって言ってます。
7割ぐらいはいけるよっていう風に言ってますね。
逆に言うと7割以上書いていくと、逆に言うとロジックに重きが大きすぎてて、
ちゃんとアプリケーションとしてがインテグレーションとか結合できてますかとか、
期待する動作っていうのをユーザーの一連のフローっていうのが確認できてますかっていうのが
おろそかになってしまいがちだったりするので、
ちゃんとその比率とかはちゃんと守る方がいいんじゃないのっていう話でした。
これについてもちょっと探るというかググっていきます。
見つかったら一緒に今日のこのツイート、朝勝のツイートと一緒に後ほど流そうと思います。
結構参考になるものだったので。
はい、洋談でした。
では続いていきましょう。
今のがインテグレーションとユニットテストの説明でした。
では続いてテスティングプライベートファンクションですね。
プライベート関数のテストっていうのを話していきましょう。
はい、テストのためにプライベート関数をエクスポートすることは良い判断ではありません。
面白い、やめてくれって感じですね。
コードがテスト可能であるべきだっていうのはそういう意味ではないですよってことですね。
はい。
テスト可能だというのとプライベートとパブリックっていうのは全然別の話なので、
それは本当想像通りですね。
プライベート関数はテストされるべきではないっていう意味ではもちろんないですよと。
はい、明示的にテストされるべきではないよってことです。
パブリックにするなよってことですね、要は。
エクスポートされない機能っていうのはそれを使用する他の関数の一部として検証される実装の詳細になります。
ですから、あるモジュールのパブリックメソッドに対するテストを書くときは、
いつでもそれが依存している全てのプライベート関数を暗黙のうちにテストすることになります。
また、公開されていない機能でカバーしたいHKSがある場合は、
その公開されている関数でもテストするようにしましょうと。
もしプライベートメソッドの全ての共同をパブリックなインターフェースで確認できないのであれば、
15:03
そのテスト用意性をもう一回向上させるように見直してくださいということでした。
それは、コードの深いところで環境変数を使っていたり、
関数の引数として渡せるはずの特定のモジュールをインポートしていたりすることを意味しますということでした。
プライベート関数もその関数自体がちゃんと動いているかどうかをテストすることはすごく大事なので、
どうやってテストを書くか悩ましいところですけど、
やっぱりちゃんと僕は書いた方がいいんじゃないと思いますね。
ただ、じゃあそれをどうやって、エクスポートされてないんだったら仕様がないじゃんという可能性はありますけど、
Mock化することもできたりしますし、
設計とかディレクトリの構成によりますけど、
テストのディレクトリをその中に置くのであれば、
その中に置いたままのテストを書くということもできなくはないなという気はしてますね。
何かしらのやり方はあると思いますし、
その関数自体がやること、
プライベートにしてしまっている理由は絶対そこにあるはずなので、
そのプライベート関数の中でもしAPIコールとかしたりするんだったら、
それはそれで何かしらテストするようにした方がいいと思います。
最悪同じような関数をテスト用にコピーしておいて、
それをテストするのがいいんじゃないかという気はしてます。
アプリケーションの中ではプライベートで結構ですね。
そういうユニットテストの流度とかテストの仕方というところで、
やっぱりそれはテストしたいというのであれば、
テスト専用にコピーをするということも最終的にはやっていいんじゃないかと僕は思ったりしてますね。
あんまりやらないですよね。
いろいろユニットテストのフレームワークって機能がたくさんあるので、
その辺からやり方はいくらでも以下用にもある気がしてますって感じです。
では続いていきましょう。
次はテスティングインプロダクションですね。
ここから実践的なお話になりますね。
本番環境でのテストはどうしようかというところです。
正直なところ私は本番環境で適切なテストを行ったことがありませんし、
今でもやりたがらないんです。
このアプローチから十分な利益を得られるような会社で働いたことがないだけだというふうにやってます。
別にメリットとか価値とかがないよというわけではなさそうで、
単純にやったことがないだけだということですね。
僕は結構ありますけど、やっぱりちゃんとやったほうがいいと思いますし、
本番環境でやれるんであれば付加試験とか、いわゆる非機能要件のテストまでやってほしいなと思います。
この記事で非機能要件の話出てくるかちょっと分からないですけどね。
本番環境で適切なテストを行うには、プルリクエストを素早く承認する以上のことが必要になります。
機能フラグのフローというのを確立し、
必要なときに素早く変更をロールバックする能力でも大切ですと。
問題を早期に発見するための観測可能なツールというのを入れてくださいということですね。
本番環境でのテストというのは、ユーザーのバグに対する許容範囲に大きく依存します。
娯楽用の製品を開発している組織というのは、そのリグレッションに対してより寛大になることができます。
しかし高いレベルの信頼と権威を維持しなければならない組織では、そのような贅沢というのはもちろん許されません。
もし私の銀行が新機能のテストを本番環境で行うようになったら、私は嬉しくないでしょう。
18:05
単純なUIのバグでさえ、私の心と胃袋というのは入れ替わることになります。
面白いなあ。海外の方のこういう比喩表現は毎回読んでて面白いですね。
はい。しかしテストは開発やステージングに限定されるべきではないという考えには大きな価値があります。
そうですね。もちろんステージングとか開発環境というところで十分に担保されたりとかテストが十分できてますよという環境ができてますというのであれば、
それをそのまま本番にアップしてもいいっちゃいいんですけど、完全に全く本番と同じような環境を作るというのはかなり厳しいと思いますのでね。
もちろん環境とかスペックとかのサーバーなんていうのはあると思うんですけど、あるので僕はやっぱりちゃんと本番環境でもテストをした方がいいというふうになんだかんだ思いますね。
アプリケーションレベルではもちろんステージングとかローカル環境だけのテストでも十分いいと思います。
それはソースコードレベルで全く同じになるというのは担保できてますのでね。
ただやっぱりそういう環境周りだったりそういう外部要因とかによって動かない結果あると思いますし、
例えばステージングとかローカル環境でその認証周りだったり、あと決済周りの機能とかを実際に自動でテストできるかってそんなことはないと思いますしね。
やっぱり本番でやって初めて意味があると思うので、ちゃんとやった方がいいんじゃないかって僕は思ったりします。
本番環境っていうのは適切な動作が当然とされるような原始的な環境であってはならないよってことですね。
実際のユーザーの行動やデータ、結局そこでしか得られないよってことですね。
はい、という感じでした。
以上テスティングインプロダクションの章でした。
じゃあ続いていきましょう。
続いてでは次がラストかな。
次ラストですね。
えーちょっと翻訳に時間かかってますね。
はい、テスティングイズナットQAですね。
はい。テストはQAじゃない。クオリティーアシュアランスでしたっけ?QAって。
ではないですよってことですね。
はい。テストっていうのはその範囲にかかわらず、道路から滑り落ちないようにするための交通障壁以外の何ものでもないですよってことを言ってます。
品質っていうのはその分野の十分な理解、明確に定義された要件、生産的な作業環境っていうところから生まれます。
ソフトウェアを作る分野に精通していないエンジニアっていうのは、そのエッジケースを特定するのがかなり難しいでしょう。
どんなに詳細なチケットを作成しても、作成者が細部を見落とした可能性っていうのは常にあります。
システムや製品がどのように振る舞うべきかっていうことを知ることは、ソフトウェアを磨くのにとても役立ちます。
なぜなら、間違った動作を検証するテストっていうのは、それがないことよりもさらに悪いからです。
これいい観点ですね。間違ったテストっていうのは、むしろ悪しか生まないっていうのはすごくいい話だと思います。
それならばテストしないほうがまだいいですね。後からやるほうがまだいいというところですね。
プロダクションのバグっていうのはテストの不足というより、不健全な理解の結果だというふうに言っています。
21:00
これはでもどうなんでしょうね。不健全な理解の結果。
結構見落としな気がしますけどね。
だいたいバグとか本番環境をリリースした後のバグって、ユーザーが使ってくれて、そのユーザーから上がってくることが割と多いと思っているので。
いろんな記事を読んできましたけど、やっぱりそういう記事が多くてですね。
なので、なんだかんだ本番のバグっていうのは大部分はユーザーとかテストの不足だと思います。
僕らの想像性の欠如と言ったらちょっとあれかもしれないですけど、やっぱり使い方って、僕らが想像する使い方ってやっぱりなかなか限定的なんですよね。
ユーザーっていうのは僕らみたいに何も中身を知らないまま触ってくるので、僕らが想像し得ない使い方っていうのは大いにあり得るんですよね。
作っている側とかテストしている側からすると中身がわかってしまって、ソースコードレベルでわかっているので、こんな使い方は普通しないよねっていうのを暗黙的に僕らは思ってしまっているっていうのをしっかり自覚しなきゃいけないなというのを思いますね、開発者っていうのは。
なので不健全な理解の結果っていう、不健全で不完全ですね。
不完全な理解の結果っていうのは、僕はちょっとこの言葉には疑問までは行かないけど、なんか引っかかりやがるなという感じがしましたね。
皆さんはどう感じるかは別ですけど。
すいません、戻ります。
テストを重視するあまり、ローカルでの開発環境を整えることの重要性をもう軽視しがちです。
高速に動作するテストスイートを持つことで、実装から結果までのフィードバックループっていうのを短縮することができます。
しかし、これは言うは安く行うは過多しです。
私はテストを1ファイルずつ実行できるようなテストツールを使うことをお勧めしますというところです。
ここに関しては完全同意ですね。
今のテスティングフレームワーク、たくさんありますね。
ユニット系だとなんだかんだジェストが確か一興だった気がしますけど。
インテグレーションとかE2Eテストとかたくさんあるので、その辺は好きなのを使ってくださいと。
僕は結構Cypressを使ったり、プレイライトが結構弊社では今流行っている感じがしますね。
あとなんだっけ、テストカフェっていうやつもありますね。
フロントエンド周りのテストのツールの名前しか出してないので、
他の言語に関しては、すみません、僕が不勉強とかやってないとわからないんですけど、そういうのもあったりしますね。
あとなんだっけ、スナップショットテストもやっぱりフロントエンドの人はやったほうがいいなっていうのがよくありますね。
スナップショットも2種類あると思っていて、ソースコードでのスナップショットを差分とってテストするっていうスナップショットテストがありますね。
いわゆるストーリーブックにそういうプラグインがあったはずなので、それを入れてやるっていうやり方がよくあるやり方なんですけど、
それと別で、レグスーツっていう別のやつがありますね。
あれはもう完全に画像をパシャッと撮って、その画像の差分を撮っていくっていう、わりと期待していたスナップショットですね。
名前の通りスナップショットを撮ったテストをしてくれるので、こっちの2通りのパターンがあると思うので、それをやっていくといいのかなと思います。
ちなみにレグスーツはサイプレスとかと結構連携もできたりするので、両方やるっていうのが最高だと思いますね。
もちろんお金とリソースと時間というのがあると思うので、そこの話はありますけど、できるんだったら全部やってみるっていうのが結構いいかもしれない。
24:04
余談がまた過ぎましたね、戻りますね。
最後、さらに付け加えると、私のこれまでの経験から問題のあるローカル設定っていうのは質の高いソフトウェアを生み出す能力を阻害する可能性があることが分かっています。
開発者がコードベースに変更を加える際に、より多くの摩擦を経験すればするほど、その機能のために余計な努力をする可能性が低くなるでしょう。
というところで、この記事は終わってますね。
要はテストするところ、ずっとユニットテストからスタートして、どんどんフィールドを上げていって、最終的に本番環境のところまで来ましたけど、
大事なのは何だかんだスタートのあるローカル開発環境のところまでしっかり継承しないで環境を作ることで、
それから生まれていったソフトウェアだったりとか、そこの環境から生まれたテストっていうのがしっかり問題というところをどんどん見つけやすくなったりとか、
フィードバックループを早めることができるよっていうような観点に戻るんですね。
やっぱり神は細部に宿るっていうことは通りだなっていう感じはしましたね。
というところでざーっと読んでいきましたけど、余談と雑談を挟んだせいで大体30分になってきたので、
本当はもう一個の記事なんだっけ。
Why We Traditioned From Sprints to Base Camps Shape Up Methodologyか。
アジャイル開発ってところに少し疑問を持ったので、それからシェアドアップっていう手法に変えましたよっていうようなもう一つの記事があるんですけど、
こっちを読みたかったんですけど、今回時間が無くなったので明日に回していきたいなと思います。
なので今日はテスティングフィロソフィーの記事を読ませていただきました。
参考だったら幸いです。
では、今日の朝活はこちらで以上にしたいかなと思います。
木曜日というところで、明日金曜日はほぼ休みに近いからあんま仕事の気分にならんわっていう方も多く、
1週間のある意味で締めというか、本気で取り組むべきはここだったりするっていう人もいたりすると思うんですけど、
まあ人による気ですけどね。
今日も一日頑張っていけたらなと思います。
じゃあ今日もご参加いただいた多くの方、たくさん大変にありがとうございました。
また明日もゆるーく読んでいきますので、興味ある方はご参加いただけたら幸いです。
今日読んだ記事は後ほどツイッターでツイートしますので、ご自身の中でも読んでいただければ幸いです。
では今日も一日頑張っていきましょう。お疲れ様でした。
