00:06
8月10日、水曜日ですね。
地獄は朝9時を回りました。
今日はいい感じの晴れてるところなので、洗濯も一気に片付けるかなと思ってます。
はい、おはようございます。ひめめのkeethこと桑原です。
ではですね、本日も朝から始めていきますが、今日は2つの記事ですかね。
ちょっと読んでいこうと思います。
ちょっとタイポってますけども。
1つは、Storybook 7.0 designのスニークピークってやつですね。
いわゆるデザイン。
Storybook 7.0のデザインについて、ちょっとチラ見せ的な。
こんな感じでやってますよっていうのをご紹介だそうですね。
もう1個は、Body Marginの8pxっていうのがブラウザについてるんですけど、
それは何でそれがついてるのかっていうのを、歴史をちょっと遡りつつも見てみようかなというところでした。
もし時間があったら、もしくは時間以降で読もうと思っているもので、
トップレギュアツーリング、インデブツールっていうのがあって、
ここも気になるなーって思ったんですけど、
ソースコードが結構出てきたりするので、後半の方は。
なのでちょっとそこは悩ましいなと思ってますので、
トップレイヤーの話は次回かな。
一応ざっと見て読めそうだったら読もうと思います。
なければまた記事の、いわゆる読み物系を読んでいこうかなと思っております。
では、早速1つ目ですね。
Storybook 7.0 designスニークピークからやっていきたいなと思います。
はい。
あ、石井さんですね。
昨晩ありがとうございました。
今日もご参加いただきありがとうございます。
じゃあ早速入っていきましょう。
Storybook 7.0ですね。
最近あんまりStorybookを触らなくなったので、
まあ案件やってないからなんですけど。
ただなんだかんだ更新は気になるところですね。
はい、いきましょう。
毎朝何千人もの開発者がStorybookを起動して、
1日の仕事を始めています。
StorybookはNetflix、Adobe、EUのフロントエンドワークフローというのを支えています。
利用が増えるにつれて、
UXのエッジケースや不整合にさらされることが多くなります。
過去3年間、私たちはユーザビリティを調査し、
UXのフィードバックというのを集めてきました。
この度にStorybook 7.0のデザインを公開することができ、
とても嬉しく思っています。
より少ないクリック、より短いマウス移動、
より少ない待ち時間で、
より多くのものを構築できるように
Core UIパターンでもリフレッシュしました。
かなりUXの根本的な観点から見直したというところですね。
大きく5つぐらいの観点から見ています。
1つ目、レイアウトの拡張により、
使用可能な領域というのが増加しました。
あと、ツールバーを整理して、
割と見やすく、発見しやすくしました。
続いて、アイコンセットというのを再描画して軽量化をしたんですね。
4つ目に、フォーム要素の改良をしたと。
ざっくり改良と書いてあるので、どんな改良かわからないですけど。
最後は、パフォーマンスのオーバーフォールですね。
はい、というところでした。
では、続けていきたいと思いますけど、
ホワインなうですね。
03:01
なんで今なの?というところですけど、
この話を続けていく前に、
7.0というのは、車輪を再設計していないことを述べておく必要があります。
ストーリーブックの人気というのは、
現在の戦場で、戦場という言い方もあるんですけど、
試された開発者の経験の証だとあります。
チームはそれを台無しにするようなことはしません。
ストーリーブックのデザインは、
私とノーヴァート・デ・ランジェンさんによって、
2009年に最後に刷新をされました。
2019年、結構前ですね。
当時は、UIコンポーネントを単独で構築するためのツールに過ぎませんでした。
コミュニティが開発に向けて、
UIドキュメントやテストにおけるストーリーブックの能力も
どんどん向上していったというところですね。
最近では、マイクロソフト、ショピーファイ、マンデー・ドットコムなど、
数え切れないほどのチームが、
耐久性のあるUIを世界中に出荷させるために、
ストーリーブックに依存しています。
しかし、ストーリーブックの機能拡張に伴い、
コミュニティが長年にわたって、
視覚的な不整合や微妙なバグにつまずくことは避けられませんでした。
7.0のデザインは、このような蓄積されたフィードバックに対応し、
ストーリーブックの将来のための基礎となるような
UIパターンを構築しています。
ユーザーとしては、使い慣れたワーククローの上に
洗練された新しいUXを手に入れることができます。
本当にさりげな再発明ではなくて、
割と刷新なんですね。
とはいえ、今までのユーザー体験ではそのままですね。
それをより改善したというところですね。
一応、画面キャプチャーがあって、
2016年、2019年、2022年という比較の画像がパッと貼ってあるんですけど、
確かにメニューが見やすくなったり、色合いが良くなったりとか、
幅が大きくなったり、プラグインが設定できるようになったりとか、
どんどん拡張を確かにしてきたなというのはありますね。
大枠としての形というかレイアウトはほとんど変わってないんですけど、
やっぱりその細かいところですね。
がやっぱり見やすくなっているなって感じがします。
2016年はかなりやっぱり簡素な感じの印象ですね。
2019年は今のものとだいぶ近いんですけど、
色合いとかもそうですしね。
ロゴのところもだいぶ変わりましたし。
だいぶ近いんですけど、まだ今のよりも、
もうちょっとシンプルというか足りない感がすごいなと思いましたね。
では続いていきましょう。
Meet the new look in 7.0ですね。
7.0の新しい外観です。
まずは見ていきましょう。
7.0ではキャンバスですね。
コンポーネントを分離して開発するiフレームですけど、
キャンバスにより多くのスクリーンスペースが下がれるようになりました。
キャンバスのサイズというのは3.5%増加し、
UIのあらゆる次元をより自由に表現できるようになりました。
なるほどね。キャンバス領域をでかくしたんですね。
私のようにストーリーブックで何時間も過ごす場合、
06:00
開発に当てられるピクセル数が多ければ多いほど仕事の効率が上がります。
すごいな。
ストーリーブックの開発してるからでしょうけど、
ストーリーブックと何時間も毎日向き合うというのは経験したことがないので、
面白いな。中の人ならではの意見ですね。
キャンバスツールバーにはUIの実装をチェックするのに役立つツールが含まれています。
マウス、キーボード、ユーザーの場合はタブですけど、
動かす量を減らすように一応構成されています。
また現在選択されているストーリーを再読み込みするリロードツールというのも追加されました。
確かにリロードアイコンがありますね。
これはブラウザ全体を更新することなくコンポーネントを再読み込みしたい場合に便利です。
これは地味に嬉しいですね。
毎回画面リロードしていたので、コンポーネントだけを再描画してくれるのはすごいありがたいですね。
それだけでパフォーマンスが変わったりしますからね。
これはナイスですね。
ストーリーブック7.0にはライトテーマとダークテーマの両方が付属しています。
テーマ設定APIは同じなので、
6.xからテーマ変数を調整すれば7.0に移植可能ですよというところですね。
続いてMade for you to reuseですね。
一応再利用できるように作られましたよというところです。
カスタマイズですね。
カスタマイズというのはストーリーブックの人気の理由の上位の一つに入ってきます。
コミュニティには400を超えるアドオンが存在します。
7.0ではインテグレーターは私たちがストーリーブック自体の開発に使用しているデザインパターンにもっとアクセスできるようになります。
それは結構いい話ですね。
また7.0にはご自身のプロジェクトで再利用できる196個のアイコンも含まれています。
各アイコンはシャープネスと認識性を向上させるために1から書き直されました。
またコミュニティから寄せられた新しい機能を取り込むために20個のアイコンも追加になりました。
セット全体では46%でも軽量化もしてますよと言ってますね。
すげー。追加したにも関わらず軽量化46%半分近く軽量したってすごいですね。
続いてトグルとかスライダーのようなフォームコンポーネントですけれども、こちらについては更新されたデザイン言語を遵守しています。
これはコントロールズアドオンでも最も顕著に見られます。
これらのコンポーネントはストーリーブックスラッシュコンポーネンツというアドオンからインポートして自分のアドオンで再利用できます。
アドオンじゃなくてこれはコア機能か。
ストーリーブックスラッシュコンポーネントからインポートしてアドオンでも利用できるようになりますよというところです。
画像をパッと見た感じそんな大差ないようなところですけど内部的な使い勝手のところがかなり変わったんでしょうね。
続いてパフォーマンスドライブズデザイン。
パフォーマンスがドライブを動かしていくというところですね。
続いてストーリーブック7.0では見た目が新しいだけではなくて使い心地も新しいんですよ。
09:01
開発フローをスピードアップする最も効率的な方法というのはストーリーブック自体をスーパーチャージすることです。
7.0ではストーリーブックをあらかじめバンドルしておきまっすぐに開始できるようにし依存関係の衝突を回避しています。
あーなるほどね。それは早いわ確かに。
そのパフォーマンス改善してくれるのはすごくありがたいですね。
ストーリーブックはなんだかんだコンポイントが増えてきたりでかくなってくるプロジェクトですね。
でかくなってくると起動自体が遅かったりするのでこれ回避してくれるのはすごくありがたいなと思いますね。
それぞれの依存関係を調査しバンドルサイズをさらに小さくしましたと。
バンドルサイズも小さくしたんですね。7.0では。
6.xでは6.xリリースのパフォーマンス改善。
7.0ではチームが何千ものストーリーを書いていても高速に起動し高速に移動することができますと。
やばいな何千のストーリーは多分書いたことないな。
ストーリーブックでストーリー最高記録いくつだろう100いってないんじゃないかな。
ぐらいしか書いたことないんでそんな超巨大なストーリー書いてたことないので。
でもそれでも高速に動くっていう風にここで断言してること多分テストしたんでしょうね。
すごいな。何千はすごいですね。
一応そこに対して細かく書いてあるんで見てみましょう。
まず7.0ですね。7.0インスタントスタートですと。
マネージャーのプレバンドルと依存関係の最適化っていうのが7.0ですね。
6.5ですね。モジュールの読み込みっていうのを高速化しましたと。
ウェブパック5のレイジコンパイルと公式ビートのビルダーっていうところを組み込んでるってことですね。
やっぱビート入ったから速くなっただけで結構デカいですよね。
ESMモジュールって素晴らしいなっていうところがありますね。
続いて6.4ですね。6.4では労働時間の短縮を実はしてたんですね。
公開済みストーリーブックのコード分割ですね。スプリッティングもしてくれたらそうですね。
6.3では将来性ってところを入れてたらしい。
ESMのサポートとウェブパック5の安定性と。
6.2で拡張性ですね。
ウェブパック5やビートなどもモダンビルダーをサポートするために
ストーリーブックを一回再設計したんですね。6.2の時点で。
6.1でスタートアップの高速化ですね。
ウェブパックのDLLっていうのを削除して
マネージャーのプリビルドとキャッシュを開始したと。
この辺を全部含めてパフォーマンス回転っていうのを
全部積み重ねてますよってことですね。
ほい。
続いて続いて。
続いてでもこれがラストかな。
ラストでサインアップフォーアーリーアクセスですね。
早期のアクセス登録ですね。
7.0のデザインっていうのはまだまだ現在開発中になりますと。
ここにあるスニークピークっていうのは最初のストロークに過ぎません。
特に早期アクセス期間中というのはデザインに命を吹き込むために
あなたの協力とフィードバックがもちろん必要になります。
ストーリーブックのメーリングリストに登録しておくと
プロジェクトの最新情報を獲得できますよと。
ストーリーブックユーザーインターフェースにアイデアをお持ちでしょうかと。
疑問ですねこれは。
ストーリーブックのディスコードチャットとかに
シャープデザインっていうチャンネルがあるのでそこに参加してください。
新人の開発者、ベテラン開発者問わず投稿をお待ちしています。
なお点ゼロデザインというのは
マイケル・アレスタッドと
12:01
ドミニック・
読めない。
これなんて読むんですかね。
NGUIENさん。
読み方しなくてすみません。
この弊社の方ですね。
っていう方がストーリーブックコミュニティ全体から
フィードバックを受けながら日々開設してますよってところでした。
ここで多分意見出しとか
感想を述べたりするっていうのも
一つのOSSとしての活動になると思いますし
何もGithubとか
ライブラリーにプルリク出したり
一周出すことがOSS
それだけがOSSではないよっていう感じもあるので
ぜひぜひ皆さんコメントしていただければいいんじゃないかなと思っています。
以上
ストーリーブック7.0の
とりあえずデザインのスニークピークですね。
まだ現在開発中なので
どうなるかわかりませんけど
一旦の初出しで
見てみたって感じですね。
大きくドラスティックに
見た目が変わるって感じではないですが
使い勝手っていうところで
本当にUXのところに
改善が見られるっていうので
地味なんだけど
かなり良いっていう改善だなと思いましたね。
皆さんも見てもらってもいいかもしれないです。
以上ストーリーブックの
記事は終了で、もう一個の方ですね。
ボディマージン8ピクセルってやつですね。
ブラウザのデフォルトスタイリングに
マージンが入ってるんですねボディに。
それか8ピクセルのなんでなんだよっていうところを
ちょっと歴史的な観点からも
振り返ってみようかなっていうところでした。
じゃあちょっと見ていきましょうかね。
ではでは。
相変わらず英語なので翻訳します。
あとフォントがちょっと見づらい。
はい。
すべてのブラウザっていうのは
ボディ要素に8ピクセルのマージンを
追加しますと。
これがボディが推奨する
デフォルトのスタイルシートの一部で
ブラウザっていうのは通常
独自のユーザーエージェントスタイルの
開始点として使用しますと。
しかしなぜ8ピクセルなんでしょうか
ってところをその由来が
何かっていうのを見ていきたいなってところでした。
一応デフォルトスタイルシートってところに
リンクが貼られてますので
ここを見てもいいかもしれないですね。
ではいきましょう。
イニシャルバリューVS
ブラウザのデフォルトってやつですね。
僕らが設定するような初期値と
ブラウザのデフォルトってところですね。
はい。
CSSのすべてのプロパティには初期値がありますと。
その初期値は僕らが設定するっていうか
CSSの初期値ってことですね。
その初期値っていうのは
ウェブ全体のすべての要素で同じになります。
ディスプレイの初期値はインラインで
マージンの初期値はすべてゼロになりますと。
初期値っていうのは
カスケードで他の値が指定されてない場合や
その場所から継承されている場合に
使用されますと。
またイニシャルキーワードを使用して
スタイルを明示的に初期値に戻すこともできます。
しかしそこで止まってしまうと
初期値は素晴らしい
リーディングの体験を提供しません。
すべての要素ですべてのプロパティが
15:01
同じだとリンクだったり
弾力だったり見出しだったりリストだったり
などの視覚的な区別がつかなくなるのですと。
で、アルティメット
CSSリセットを使えばそれがわかります。
アルティメットCSSリセットっていうのは
これは多分ライブラリーっぽいかな?
2019年の記事のリンクが載ってますけども
ここでちょっと見てみてください。
で、その中に
一応ソースコードの書き方があって
これですね
アスタレスクスペースで
設定されているので本当に全要素って感じですね。
に、オールコロンイニシャル
ビックリインポーターと
っていう感じで超無理やり
リセットをかけているって感じですね。
はい。
で、
これについて
このため要素ごとに異なるデフォルト値を提供する
ブラウザーのスタイルが
必要になりますと。
一部の要素っていうのはディスプレイブロックであるべきであり
ディブとか段落とかリスト見出しなどなど
っていうのですね。
これらの要素の一部には読みやすさを向上させるために
余白がもちろん必要になりますと。
リバートキーワードっていうのを使用すると
指定された要素の任意のプロパティを
ブラウザーのデフォルトスタイルに戻すことができます。
技術的にはこれは
ブラウザー起源のスタイルを全て削除してしまいますけれども
ユーザー起源のスタイルは
稀なのでブラウザー起源のスタイルになることが
よくありますと。
まあまあそうですよね。
続いて
スタンダーズイングブラウザーデフォルトですね。
ブラウザーのデフォルトの標準化というところですけど
ブラウザーのスタイル
っていうのは重要ですけど
間違っているとか予想外だと感じたときに
初めて気づくことが多く
リセットや標準化というところで解決すべき
問題だと考えてしまいますと。
それはありがちですよね。
リセットというのはデフォルトを削除して
より真っ白なキャンバスを実現するために
使いますと。
いわゆるスタンドライズなので
ノーマライゼーションか
標準化というか正規化というか
ちょっと日本語するの難しいですね。
ノーマライゼーションですね。
デフォルトをブラウザ間でより一貫したものに
しようとするものですと。
ノーマライズってそういう観点ですよね。
真っ白にするんじゃなく
とにかくリセットするわけではなくて
ブラウザ間での一貫したものというところに
重きを置きますと。
CSSワーキンググループとブラウザベンダーというのは
デフォルトのスタイルが異なるブラウザ間で
より一貫性がある場合に
最も効果的に機能することも
我々は理解していますと。
ブラウザは自由に好きなスタイルを提供できますが
ほとんどのブラウザのデフォルトというのは
CSSの仕様ですね。
で、提供されている
しかも正規化されていないデフォルトのスタイルシートに
遡ることができますと。
もっと新しい場所もどっかにあるはずなんだけど
見つけられませんでしたというところですね。
で、書いてたんですけど
そこに打ち消し線があってアップデートが続きがありますね。
推奨させる
デフォルトスタイルというのは現在
CSSの仕様ではなくて
HTMLライビングスタンダードの一部という風になっていますと。
HTMLライビングスタンダード
というのを僕は知らなかったんですけども
これもリンク貼られているので
見ていただければと思いますね。
これWATO AGの
18:01
ドキュメントにちゃんと書いてあったってことですね。
はい。
で、一応CSS2.2の
デフォルトスタイルシートというのが
WATO AGとか
なんだっけ
CSSのデフォルトスタイルのところを決めている
CSSWAGというコミュニティとか
があるんですけどそこで定義されている
2.2のデフォルトスタイルシートというのも
一応記述に載っていますのでここで見てください。
さすがにこれ音読すると長すぎるし
これソースコードなので
たまに理解できない気がするので
みなさんで見てくださいというところですね。
では続いていきましょう。
はい。
ブロック要素には
ブロックの表示、テーブル要素にはテーブルの表示
リスト要素にはリスト表示と
当たり前のスタイルというのもあります。
見出しはより大きく、より太い文字で
表現されます。
しかしその他のデフォルトスタイルというのは
かなり詩意的に見えます。
3分の1ほど読み進めたところでこのようなものが見つかりました。
さっきのデフォルトスタイルシートを
ガーッと眺めていって
3分の1ほど読み進めたところで
このような記述。
このような記述というのが今回のタイトルにあります
ボディのマージンですね。
マージン8ピクセルというのが
目につきました。
はい。
ドキュメントの端にある程度の
デフォルトスペースが必要なのはある程度もちろん理解ができますが
なぜ8ピクセルなのかというのと
これがどこから来たというのを
今からやっと深掘りをしていくところですね。
割と前提が長かった。
で、いきましょう。
EVER GOES AWAY COMPLETELY
完全になくなることはないよ
と言ってますが
デフォルトのスタイルシートというのは
ブラウザー間の一貫性を確保するためだけでなく
時間を超えた一貫性を
確保するためにも存在します。
ウェブ全体は前方および後方との
互換性を保つように設計されています。
これはウェブが静的であるということではなく
常に新しい機能が
追加されているということです。
しかしそれらの新しい機能が既存のウェブサイトを
破壊してはならないということにもなります。
まれにプライバシーやセキュリティの問題がある場合
ブラウザーというのは既存のサイトを
破壊することを
決定することがあります。
しかし私たちはそのような事態を避けるために
できる限りのことをしています。
また多くの場合ブラウザーというのは
古いマーキー要素のように
実際にサポートを削除することなく
機能を非推奨にすることを選択しています。
ブラウザーのデフォルトスタイルも
同じようなパターンに従っています。
CSSが初めてブラウザーに実装されて以来
ブラウザーのデフォルトスタイルは
もちろん存在しています。
そしてブラウザーは時々新しいデフォルトを
追加しますが、古いデフォルトを削除するのは
非常に珍しいことですよと。
やっぱり
広報互換性のところですね。
前方か?どっちだっけ?
デフォルトに依存して作られたサイトが
壊れる可能性が高すぎるからです。
そこですよね。本当に。
だからこそ標準化というのは
難しかったりするんですけど。
現在のブラウザーのデフォルトスタイルの
多くは、HTML要素が最初に
導入された当時のデフォルトと
結構同じですよと言ってますね。
削除できるものは
別に削除してもいい気はしますね。
HTML4、3とか
21:00
本当にもっともっと前の
HTMLに立脚したCSSは
もう使ってるサイトがそもそもないと思いますし
HTML5の標準で
やっていいんじゃないかという気はしますけど
全世界に影響する
って考えた時にそこは怖いですよね。
やっぱりね。
続いて
Purity Versus
Reality In Specification
ですね。
使用における純度VS現実
ってところですね。
標準の開発に影響を与える
もう一つのルールがありますと
これはデフォルトのスタイルシートのような
非標準の標準
コンフォーマンスのために公式に要求されていないもの
という風に書いてますね。
で、あってもですと
現実を記述していなければ意味がありません。
成功するためには標準
っていうのは規定的
ブラウザに何を実装すべきかを提示する
べきだよっていう風にあると同時に
えー
やばい読めない。
やばいなーちょっと日本語読めない
これはひどいっすね。
まあ長く続くみたいな感じだと思いますけど
削給と読むんですね。すいません僕は
削給というのは読み方知りませんでした。
はい削給的に
記述的だと
実際何を実装したかを記述する
っていうものでなければならないんですよと。
理論的には完璧な
仕様であってもそれがwebを正確に
記述したいのであればもちろん役に立ちませんと
言ってます。で私たちは
えー新しい機能がどのように
機能すべきかっていうのを説明するために
新しい標準っていうのを書いて
ドキュメンテーションで書いておいてそしてブラウザが
その機能を仕様通りに実装することを
期待しますけども
それはより複雑な行き来するプロセスの
最初のステップにすぎませんと。
結果実装するのは各ブラウザベンダーですからね。
はい。
私たちはまた機能が実装された後
実際どのように動作するかを
反映するために定期的に既存のスタンダードを
見直し改訂もしています。
理想的には実装が
仕様と一致しない場合はそれはブラウザの
問題であると考えブラウザを修正したい
と思います。しかし時には
変更の大きさ変更が必要な
ブラウザの数影響を受けるサイトの数
によっては仕様の方を
更新することもまあまあありますと。
CSSの設計に間違いが
生じるのはそれだけが原因ではない
ですが
間違いが生じた時に修正し
にくくなりますよねというところですね。
繰り返しますけど我々は
標準自体の理論的な純粋さよりも
やっぱりブラウザや時間を超えた
一貫性の方をやっぱり優先
していますと言っています。結局
使う側のことを考えるというのがやっぱり
優先だということですね。
まあ確かにそれはそうだよな
なんのためのCSSだ
という話はやっぱり出てくるので。
続いて
マージンオンオール
アワーボディーズか。
ボディ全体への
マージンというところですね。
先月私はこのスタイルへの起源を追いかけることに
しました。ボディへマージン8ピクセルですね。
このスタイルがデフォルトのスタイル
シートの一部であることはもちろん知っていましたし
初期のブラウザによって提供され
ウェーブとブラウザの
24:00
一貫性を保ったために最終的に標準化された
レガシーなスタイルであることも想定
していました。
しかしこのスタイルは元々どこから来たんでしょうか
というところの疑問から
Twitterで質問してみたらしいですね。
してみたらほぼ突き止めることができました。
2個の
投稿がありますね。
で、いきましょうか。
ステップ1ですね。ステップ1
っていうのはザ・スペシフィケーション
使用書ってところですね。
アラン・スターンズ
っていう方がいらっしゃるですね。
現CSSワージーの議長の一人だそうですね。
ワージーの一人で議長
でもある方が
デフォルトのスタイリングシートに8ピクセルのマージンがある
っていうのを最初の仕様を示してくれた
っていう風に言ってますね。
そのツイート内容も一応翻訳して読むと
スペック的には
2003年の
W3Gの
リンクですね。
初めて登場してますと。
前年のバージョンではパディング8ピクセルになってたと
実は。
2003年で
パディング8ピクセルっていうのが
最初にW3Cの
ドキュメントに出てきてるけど
元々はその前年だから2002年
2002年までは
パディング8ピクセルだっていう風におっしゃってますね。
全然知らなかった。
っていう投稿のちょっと後ですね。
おっと一つずれてましたと。
2003年に
パディングもありましたと。
2004年にマージンに変更されています
ってところでしたね。
結局はまずはパディングがベースだった
っていうのが
一応
仕様書レベルでの観点でそうなってますよ
ってことが一つでした。
楽しくずっと読んでたんですけど
気づいたら30分超えていたので
どうしようかなー
ここから
まだ長いんですよね。
実はこのブログまだ半分ぐらいしか読めてないので
明日に回します。すいません。
ちょっと中途半端がしいんですけど
明日やりたいと思いますので
またマージン8ピクセルが
その期限について
また明日改めて読み直していきたいなと思います。
というわけで
今日の朝活動はこちらで以上にしたいと思います。
気づいたらすごく多くの方に参加いただき
ありがとうございました。
僕はずっと有給を取っているので
仕事なのかお休みなのかよく分かってないんですけど
こんなに参加されるとちょっと思ってなくて
かなり驚いてますが
とても嬉しく思います。
というところでまた明日
この記事続きと
せっかくCSSの記事ばっかりあるので
次はJSの記事なんかないかなというのを
見つくろって読んでいきたいなと思いますので
また明日もゆるっと参加いただければ幸いです。
では本日の朝活動はこちらで以上にしたいと思います。
お仕事の方は今日も一日頑張ってください。
暑いので体調管理も気を付けてください。
というところですね。
ではではお疲れ様でした。
