00:04
はい、7月11日、地獄アーサック城を回りました。月曜日ですね。
はい、今日はいい天気で、皆さんもいい天気だといいなと思います。
はい、おはようございます。ひめみんのきーすことくがはらです。
本日も朝活を始めていきたいかなと思います。
たまにTwitterスペースを見てるんですけど、
トピックのツイートをできるみたいな感じで、
どうやってみんなやってるのかすごく気になります。
ちょっといろいろいじってみたいな。
せっかくなのでこのままで実験してみようかなと思います。
これで設定できるのかわからないな。
みんなどうやってるのか。まあいいや。
じゃあ本日読んでいく記事ですけど、タイトルがあるとですね、
The collapse of complex softwareという記事を読んでいきたいと思います。
もし時間が余ったら、Declarative Designという記事を読んでいきたいなと思っています。
前者の方ですけど、この記事ですけどね、
昨日読んでみて、個人で読んだんですけどすごく面白かったので、
改めてこの場で読みたいなと思った次第でありますという感じです。
じゃあ早速翻訳をしていきたいんですけど、
こっちのDPLがなぜか調子が悪いんで、ちょっと待ってくださいね。
パソコンが固まった。
えーっとですね。
そして、これ今トピックは設定できてるのかな。
いまだにTwitterスペース何度も何度もやっておきながら使い方がよく分かってないんですけど。
はい、こうなっていて、これだとツイートしてるだけですよね。
はい、了解です。
えーっと。
どうやってもDPLさんが復活してくれないので、
一回プロセスを落としてしまおうかなと思います。
えーっと、DPLが死んでプロセスをぶっころ、強制終了しといて。
よっしゃ、改めて起動して。
えー、遅いな。本当に遅いな。
しない可能性が多いにあるな。
はい、じゃあGoogle翻訳いただこう。
えーっと、気づいたら4名の方ですかね。
はい、さかぎわらさんとまさきわらさんとくぜらさんですね。
はい、おはようございます。ご参加ありがとうございます。
今日朝1から割とグダグダしてますけど、ゆるりと参加いただければと思います。
03:05
これがですね、Googleです。
で、日本語に翻訳してください。はい。
えー、じゃあいきましょうかね。はい。
えーっと、今回の記事は1998年に、
人類学者のジョセフ・テイナーさんという方が書かれた書籍があって、
The Core Episodes of Complex Societiesという複雑化した社会みたいなところの論文を出されているんですけど、
それに対して、実はソフトウェアについても関係あるんじゃないかみたいなところの観点で、
今日はこの記事を書いているということですね。
はい、彼はですね、ローマ人とかマヤ人とかチャコ人などの偉大な文明の攻防について実は説明をしていますと。
で、彼の目標って何世紀にも渡って思想化を悩ませてきた疑問っていうのがあって、
それに答えることが彼の書籍の論文ですね、目的だったんですけど、
その問いというのは、なぜそのような強力な社会とか文明というのが崩壊したんですかっていうところの問いですね。
これが思想家たちの悩みというか課題だったらしいですね。
で、それに今回は回答をしていくというような話になりますというところです。
で、彼の分析を見ていくとテイナーさんは、
これらの社会の主な敵がいわゆる複雑さとか複雑性であるということが最大の敵だったというふうにおっしゃっているんですね。
で、文明が成長するにつれて、
基本的には社会とか文化というのはどんどん複雑化を増していくようになっていくというのはどの時代も変わらないんですけど、
より多くの階層であったりとか官僚主義であったりとか社会構造のより深い絡み合いとかがありますと。
で、その早い段階でこれはどんどん起きてくるんですけど、それはもちろん利にかなっているんですね。
進化の過程の利にはかなっていると。
で、その複雑さの新しいレベルごとに経済的生産高とか税収とか、いろんな点で報酬をもたらされているのは確かにあると言ってますね。
なんですけど、ある時点でその、
なんですか。
その複雑さの新しいレベルごとに準利益が少なくなって、ゼロ以上に減少するというようなそういう点があるらしいですね。
しかし複雑さというのは長い間うまく機能もしているので、結局社会は動いていたんですけど、
結果的にその複雑さがどんどん増していくと社会はそれに適応できなくなってくるという層があるんですね。
その複雑さというのはいくつかのレイヤーがあって、新しい層がそれぞれゼロまたはマイナスの投資収益率をもたらし始めたとしても、
人々は過去にうまくやっていたという事例をもう1回繰り返すと、何度も何度も繰り返そうとして、同じようにやろうとし続けているらしいですね。
06:04
そういう歴史を人類は繰り返して毎度毎度滅びているらしいですね。
彼らがある時点で構築したモラスというのがあるんですけど、それは非常に機能不全になって扱いにくくなって、
唯一の解決策は結局作り直すために1回崩壊させるしかないねというのが唯一の解決策になるらしいです。
つまり通常は古いシステムを廃止してゼロから始めることによって、急速に複雑さというのを減少させるというのがよくやり方だそうですね。
私がこれについて魅力的だと思うのは、特に現在文明からの影響が大きいらしいんですけど、
この点について魅力だと思うのは、テイナーさんが実はソフトウェアについて書いていた可能性がないのかなというふうに思った次第らしいですね。
特に大規模な組織とか、テクノロジー業界で十分長い間働いてきた人というのは、
誰でもこれまでに同じようなものを見た経験があるとは思いますと言っていて、
例えばレガシーシステムとかがまさにそうだと言ってますけど、
それはとても巨大だったり肥大化していて、すごく複雑化していると。
その仕組みを完全に理解している人は誰もいませんと。
なんで動いているのっていうのをちゃんと把握している人は実はいなかったりするよと言ってますね。
アーキテクトの人方は、そのシステムを修正するために結構連れてこられるらしいんですけど、
彼らはボックスと矢印ってよく言うんですけど、
例えばホワイトボードとかにシステム構成図を書くときに箱と矢印をひたすらばーっと散りばめると思うんですけど、
そこを今回例えに出しているんですけど、
多くのボックスと大きな矢印を示すホワイトボードをガチャガチャ動かしていくかもしれませんけど、
必然的に彼らの解決策はその大きなボックスと矢印のホワイトボードの図に、
でっかく赤文字でバツ印を書きますと。
もうこれは無理ですと。
いうことがよくやるやり方だと言ってましたね。
先人の今までのシステムをもう一回ぶち壊しましょうってことだそうです。
こういうことをしないと結局誰もシステムから引き算をしたりとかなんちゃらしたりすることはなく、
結局そのボックスと矢印をどんどんどんどん追加していって、
要はシステムとか要素をどんどん追加していくんですね。
その場その場に必要だったりとか要件だったりとかを後から足していっているから、
どんどん複雑さが増しているよって話で、
引き算をすることは誰もしないとっていうことらしいですね。
それが積み重なってどんどん複雑さが増していくっていうことを言ってます。
それについては続けて読んでいくんですが。
この現象っていうのはいわゆる追加して複雑さを増していくっていうこの現象は数年間続くかもしれないですけど、
ある時点で組織の混乱が発生することが多いにあるよると。
例えば組織の合併だったり3位編成だったりすることもありますけど、
そういうことをするときにしばらくの間ですね。
いわゆるそういうことをやってきた上級管理者っていう人たちがいるんですけど、
その人たちに趣味に没頭してもらうために定調に1回解散というか、
09:02
この席を譲ってくださいってどっかに追いやるしかないっていうことを言ってて、
新しく入ってきたアーキテクトの方々とかが登場して、
そのでっかいボックスやジェルシーの大きな図に対して解決を図っていって、
とにかく赤い×辞書を書いて1回作り直しましょうっていうことを言うわけですね。
それができる組織ならば別にいいんですけど、
できない組織はなかなか複雑さをどんどん増していって、
一緒に崩壊していくしかないなっていう結論っぽいですね。
その古いシステムをどんどん廃止して、
またはそれに取り組んだ厄介なベテランを排除していくというところですね。
プロジェクトを再編して新しいチームの人が新しくシステムをゼロから設計するようになるっていうのが、
今までやってきた方法ですっていうのを言ってます。
繰り返し述べてる感じですね。
時代を超越したとかもしくは永続的に長く使われるみたいなソフトウェアを作りたいっていうのが、
結構僕らのよく熱望する要望ではあるんですが、
残念なことにですね、このレガシーとか複雑さを増したシステムっていうのは、
残念ながら今現実として一旦機能しているっていうことを認める必要もあります。
その無駄であったり非効率的だったり、すごい傲慢さみたいなところですね。
古いコードは機能しますけど、古いコードはひどいっていうところですね。
に立ち返らなきゃいけないんですけど、
にもかかわらず過去数十年に多くのソフトウェア会社が伝えてきたモデルっていうのは、
こういうひどいモデルなんだっていうところを一回認めましょうと。
このサイクルですね。
そうやって複雑さを増してって崩壊してっていうこのサイクルって永遠に続くのかっていうところに疑問を持ち、
この弊社の方は思っていて、
私はこのサイクルが永遠に続くとは思っていませんと。
例えば現在ソフトウェア業界っていうのはほぼ20年間経済ブームにあると言ってます。
経済的に伸びているっていうブームが続いてるよっていうふうに言ってますね。
経済学で確実なことの一つとしては、
ブームっていうのは最終的に崩壊するときが一回来るよって言ってますね。
そのブームの間ソフトウェア会社ってのは既存のソフトウェアを管理するために結構新しい人員をどんどん雇い続けたり、
より多くのエンジニアが多くのボックスや印を理解する必要がありますけど、
どんどん雇用は続けることはできたんですけど、
労働力の契約を余儀なくされると同じシステムを維持できない可能性ってのも出てくるよって言ってますね。
その複雑さの迅速化と永続的に軽減することが唯一の長期的な解決策になる可能性があるよって言ってますけれども、
それをできてるシステムとかアプリケーションがどれだけあるのかっていうのはまた別の疑問ですねってことですね。
ただしですけど、複雑さを優先して機能させることの一つはエンジニアが複雑さを一旦好むことだって言ってます。
認めてくださいねって言ってました。
言ってもエンジニア自体がそもそも複雑さは結構好きなんじゃないのっていうふうにこの人は言及していて、
実際他の人の複雑さに不平を言ったりとか指摘をしたりするぐらい実は僕らは複雑さっていうのを愛してるよっていうふうに言ってますと。
12:01
これは結構面白いシステムですね。
言われてみれば確かに複雑なんですよねシステムっていうのは。
確かに複雑な代わりに結構責任分岐をしっかり分けてたりとかスコープを分けたりとかしているので、
そりゃそうなるよねっていうのは分かるんですよ。
なので一概に複雑がだから悪いっていうわけでもなかったりします。
実際にメリットも大きいですからね。
我々は頭の中でいろんな設計をしたりとか構築したりとか妄想したりっていうのを考えることが本当に大好きで、
それをさらに現実に落とし込んでいくのはもっと好きなんですけど、
これらの図というのが頭を離れ、現実の世界に形になって一人の頭のサイズを超えて初めて問題が始まるということですね。
だから自分自身の中、一人の人間の中の頭の中の設計とかデザインを物事にどんどん落とし込んでいくんですけど、
それが他の人たちと関わっていって、自分の設計してたものをさらに超えてきたサイズになってきた瞬間から問題はスタートしていくということですね。
だから自分だけで閉じていればぶっちゃけ問題はそんなに起きないといけます。
続いてその新しいボックス、コンポーネントだったりするんですけど、
矢印にNOを言うためには複雑に抵抗するために多くの規律だったりルールが必要ですよと。
例えば何かを追加するときに一回NOを言って、その問題はまだ解決しないとか、
もう想像しなかった10の新しい問題が発生するだけだからですとか、例えばですね。
もしくは少なくとも我々が理解できるのは素人っぽく見えてももっとシンプルなデザインでいきましょうというふうに言ったりするとかですね。
あまり素人っぽいシンプルな方法って確かに好まれない傾向はありますけど、
一回まずはシンプルなデザインでいきましょうっていうのは結構大事なことかもしれないですね。
とか、もしくは多めではなく少なめにしましょうとどけ、どんどん言ってってくださいと。
よくある話ですけど、システムのよく使われる機能って全機能のうちの大体2、3割ってよく言われたりしますからね。
だからあれもこれもって言うんじゃなくて一旦引き算していきましょうっていうのは結構いい話だと思います。
こういうことを設計とかするときに実際にこういうことをどんどん言っていくっていうのは確かに大事だと思いますね。
デザインのシンプルさ、設計の話かな今回は。
のシンプルさっていうのは理論的には素晴らしいように聞こえますけど、
それはあなたがあなたの仲間から多くの賞賛を獲ることはできないかもしれませんと言ってます。
複雑な設計とはシステムのより多くの部分を管理するためのより多くのチームとかエンジニアを行うために多くの会議とか多くの特許を申請することを意味しますと。
シンプルなデザインでは実際に仕事をしていないように見えるかもしれませんと。
その程度でおしまいなんですかね、終わったんですかねみたいなとかいうふうな問いかけも投げられたりしますけど。
そしてこういうことをしていくと、例えばこのプロモーションシーズン、いわゆる査定のタイミングが近づいてくると、
僕らがよくやってきたシンプルでわかりやすいデザインっていうのがあまり評価されないかもしれないですねと。
15:01
結構複雑であったりとか、例えばモダンであったりとか、いろんなものを加味したソリューションの方が自分の主張も立てられますし、
評価されるかもしれないねっていうことを言ってます。
なのであまりシンプルなデザインにして実装していくと、あまりアピールポイントが少ないんですよねっていうふうに見られるかもしれないっていうのを仰ってます。
これは何とも言えないですね。会社の文化とかにもよるかもしれないですけど。
では最後に、個人的にはこの状況について、ユーモアなセンスとかを持って例えば霊性とか絶望に屈することを避けようとしていますと言ってますね。
ソフトウェア自体を書くのは本当に楽しいんですけど、現在の業界で非常に永続的ではないような状況になることは否めないなとも言ってます。
例えば10年前に書いたコードが使用されているっていうのは多くのことをその代わり理解する必要もありますってことですね。
10年前に書いたコードが生き続けているシステムってそれ時点で十分すごいと思います。
特にソフトウェア業界で10年間続くコードなんてなかなか見たことないですから。
そうでない場合は少なくともソフトウェア開発者の大多数を占める可能性のある他のメンバーとは両方の関係にあります。
日本語訳難しいな。英語そのまま読んで翻訳できたら一番いいんですけど。
できる限り最善を尽くして野蛮な建築家、アーキテクトがたくさんの箱とか矢印の大きな図を描くときは、
健全な会議的議論を持って臨んでいってくださいねっていうことでした。
そういう締め方をされてますってことですね。
結局立脚するところは1988年の高齢プソブコンフレスソサイティということで、
社会の複雑さによる崩壊っていうところからソフトウェア自体も同じことをやってるよねっていうような観点で物事を見ていったんですね。
結局複雑さを増していくとメリットとデメリットも両方あるんでそこは理解しつつ、
ちゃんと最初から複雑さにどんどん走っていくっていうことをせずに、
本当にそれ必要なのかどうかっていうのをちゃんと会議的な目を持って臨んでいってくださいっていう結論に書いていたって感じですね。
というところでした。
割と僕はこれ面白かったんですよね、読んでて。
言われて確かにそうだよなって思う人もたくさんあってですね。
とにかく特に僕はクライアントワークをすることが多くてですね、
お客さんと話してるときにやっぱりお客さんって後からあれもこれもってすごく言ってくるんですよね。
それに対して僕らがNOって言ったり、このパターンのときはどうですかとか、
こういうときって結局使われない可能性ありますよねとか、
これ長いことずっと続く予定なんですかといろいろ問うてみるとですね、
なんか強力的じゃないって怒られたりすることもありますし、
人によっては嫌悪感を示される方も結構いらっしゃって、
なかなかビジネスって難しいなと思いながらですけど。
いわゆるMVPっていう考え方があって、
本当に必要なものを必要なとこはタイミングで入れていく。
リリースとか段階とかを経てどんどんシステムを拡張大きくしていくっていうのがいい話なんですけど、
なんだかんだ言うて最初から全部詰め込みたがるっていうのはやっぱり人間の差がなのかなと思ってますね。
できることがそのおかげで増えるのでそれはそうだとは思いますけども、
18:01
結果複雑さしたものをちゃんとメンテナンスするのが必要もあるし、
それを理解して一緒に付き合っていかなきゃいけないっていうところも出てくるので、
だから複雑さっていうのは本当に、
要法要領を守りください的なお話になるなっていうのはちょっと感じました。
この掲示自体本当にいいと思うので、皆さんの方でも読んでいただくといいのかなと思います。
一応昨日ツイートしたのでそこ活動ってもらえるといいのかなと思いました。
時間あと10分くらい余ったのでもう1個ですね。
以前リクラレイティブデザインシステムって言って宣言的デザインシステムのお話を読んでたんですけど、
それの大元となるデクラレイティブデザインですね。
宣言的デザインそのもののほうの記事が書かれてるっていうのを見たので、
それもちょっと今日読んでいきたいかなと思います。
そんなに長くないはずなので、もしかしたら早めに終わっちゃう可能性はありますけど、
ちょっとゆるーと読んでいきたいと思います。
やっぱりですけど、DeepLが起動してくれないですね。
今3回くらい再起動したんですけど無理でしたね。
かつDeepLとGoogle翻訳だとやっぱりDeepLのほうが翻訳精度高いですね。
読みやすいもん。
今回のGoogle翻訳ちょっと読みづらいなと思いました。
なので、ちょっと理解しづらい文章だったらごめんなさい。
じゃあいきますね。
デクラレイティブ。
デクラレイティブって読むのかな?
これはデクララティブって読むのかわかんないですけど。
デザインですね。宣言的デザインっていうの入っていきたいと思います。
過去数年間同じような考え方を共有する多くのウェブデザインアプローチがあったように感じます。
ジェンっていう方がいるんですけど、ジェンによる本質的なウェブデザインとかがそうですね。
あとはアンディとヘイドンって人ですかね。
によるすべてのレイアウトとか、トライとチェームズによるユートピアみたいなのとか。
いろんなものがあったよって言ってますけど。
これら一個一個についてまた記事のリンクもあるんで、
後ほどこの今読んでる記事のリンクを送りますので、
その中からまたリンクたどってもらえればいいのかなと思います。
ある程度それらの強みっていうのはCSSの技術的進歩ですね。
Flexboxもありまして、Gridもありまして、CALCUなどの計算もできるようになりましたというものもあります。
しかしもっと重要なことっていうのは、
彼らはアプローチを共有していることだとおっしゃってます。
それらは可能なすべての出力を制御しようとするんではなくて、
適切な入力を作成することに焦点を合わせています。
これらの出力に最終的な計算っていうのはブラウザに任せています。
これがコンピューターの得意分野だっていうふうにおっしゃってますね。
今のところそうなった感じでした。
アンディという方が言うように、
マイクロマネジメントをするのではなくて、
ブラウザのメンターになりましょうというふうに言ってます。
なるほどね。
Utopiaのアプローチを振り返ってみると、
ジムニール線を次のように書いています。
CSSっていうのはあくまで宣言型と言いますけど、
Viewport Spectrum全体でデザインを変更できる様々な方法に対応するために、
ブレークポイントを作成するというほど、命令的コードを作成するように感じます。
一連の宣言型ルールっていうのはどのくらいの量で、
21:01
命令型の指示が見え始めますかというふうな問いを投げてますね。
CSSがそもそも宣言型の書き方をしなきゃいけないので、
仕方ないかもありますけど。
結局後勝ちになったりしますしね。
対照的にUtopiaの原則の一つっていうのは、
宣言型であり、実行方法を指示するのではなくて、
実行する内容を説明することだとおっしゃってますね。
なるほど。
宣言型だと。
いわゆる実行方法の指示とか命令をするんじゃなくて、
その内容を説明するというところに重きを置いてくださいということですね。
このアプローチでは任意のビューポート幅を選択して、
数式を使用して、そのタイプのサイズと間隔を同質的にしますと。
そういうような一連のルールを宣言しますよと言ってますね。
宣言型っていうのは、それはUtopia全てのレイアウト、
本質的なウェブデザインの間の共通点を説明するために
私が探していた言葉だとおっしゃってますね。
なるほど。
まずはちょっと続けていきますね。
宣言型のデザインがもしものであるのであれば、
それはまた命令型のデザインもものであるということを意味するか
という問いを一回投げてて、
そして命令型設計のためのツールとテクノロジーは
どのように見えるでしょうかというふうにおっしゃってますね。
最近出てきたツールとして、テイルウィンドっていうのは
設計ツールの良い例かもしれないと実は思っています。
それは特定のアウトプットについてだけだと言ってて、
体系的な指向は積極的に推奨されていませんと。
代わりに画面の最後のピクセルを正確に指定しますというところですね。
テイルウィンドはそれはユーティリティクラスの
集まりなのでそれは仕方ないなと思いますね。
Utopiaのような宣言型ツールが正しいと言っているのではなくて、
テイルウィンドのような命令型ツールが間違っていると
言っているわけでもないとおっしゃってますね。
別にどれかが良い悪いというふうなことをここで言いたいわけではないと。
それは異なっているからですね、そもそも。
目的とかどこから解決するかどうか、
何を解決するかというのは別々のものですからね。
この場合それは我々が持っている考え方に依存しますよねと言ってます。
この声明に同意する場合はおそらく命令型の設計ツールを使用するというのが
パターンとしてあり得ますと言ってますね。
CSSが壊れているのでCSSが設計された方法でツールを機能したいと思っています。
ただしこのステートメントに同意する場合は宣言型の設計ツールを使用する場合が
必要がありますと言ってますね。
ってことは結局だいぶ前に言っていたこのステートメントですね。
一番最初の問いの方が、
宣言型のデザインがものであるならばそれはまた命令型のデザインものであることを意味するかというところと、
命令型設計のためのツールのテクノロジーはどのように見えるでしょうかというところですね。
この問いに対してどう思うかによって命令型にするか宣言型にするかというのを変えてくださいと言ってますね。
24:03
その問いとかに同意した場合は
Utopiaとかやすべてのレイアウトみたいな冒頭に出てきた宣言型ツールを使用すると
おそらく悪い時間を過ごすことになりますと。
あなたはおそらくそれを嫌に思うでしょうと
ツールを不良と宣言するようになるかもしれませんと言ってますね。
要は問いに対して自分がどういう態度をとっているかによって命令型宣言型を使うんですけど
その選択を誤ると選択したツールっていうのが悪いものと
なんならあなたはそれを嫌うことになるでしょうというふうにおっしゃってます。
これ結構いい話をしていて
ツールが悪いわけじゃないと思うんですよね。
ツールはあくまで道具でしかなくて
それが物事を解決するものっていうのはそのツールの設計者の思想とかがあったりするわけですね。
そこを理解しないまま誤ったケースで利用したから
そのツールを悪いというふうに評価をするというのは違う話だと思って
使い方はあなたが誤っただけだというところが重要だと思います。
エンジニアの方々によくこのツールはもうひどいとかダメだとか
結構おっしゃる方がいらっしゃると思いますし
エコ精髄はありますよね。
このツールがもう古くなったりとか
メンテナンスしなくなったとか
現代の技術に応えてないという話は絶対出てくると思って
そういう意味で悪いっていうのは
まあまあ理解はできます。
ただ悪いという言葉を使うのが僕は良くないと思うんですね。
もう今の現代では使わなくなったとか
解決するものが現代のものを解決できなくなったという話で
要はそういう選択をしないという判断をするだけの話だと思っていて
良い悪いっていうのはちょっと違う気がしますね。
もちろん本当に悪いツールもありますよ。
セキュリティインジェクションがバンバン発生しまくったりするとか
ドキュメントも全然なかったりとか
使ってみて初めて出てくる仕様があるとか
そういう悪いツールってもちろんあったりするんですけど
そういうの除いてということですね。
バンバン余談が過ぎましたのでまた本文に戻りたいと思います。
同様に2番目のステートメントに同意した場合
テイルウィンドウのような命令型ツールを使用すると
おそらく同じように悪い時間を過ごすことになるでしょうと言ってますね。
それらすべてツールの背後にある哲学とか思想っていうのが
あなたの自身の哲学とかと一致するかどうかに依存しますと。
これらの哲学が一致すればツールを使用することは成端的であって
そのツールはマッチするアンプすると言ってますね。
心の自転車として機能するよって言ってます。
同じにツールの哲学が自分の哲学と一致しない場合は
そのすべてのステップでツールと伝えることになり
速度が低下する、ベロシティ下がるよって言ってますね。
このスペクトルが宣言型ツールと命令型ツールの間に存在することを知っていると
テクノロジーを評価するときに役立ちますと。
CSSが壊れているという前提でまたはCSSが素晴らしいという前提で
Webデザインツールが出ているかどうかっていうのを評価できますよって言ってますね。
27:00
Webデザインと開発へのあなたの道はあなたが特定するスペクトルの
どちらの状況にも影響を与えるのではないかと思います。
例えばバックグラウンドがHTMLやCSSのような宣言型言語である場合は
おそらく本質的なWebデザインっていうのは本番に共鳴しますと言ってますね。
しかしあなたのバックグラウンドがJavaScriptのような命令型言語である場合っていうのは
おそらくテイルウィンドの方が利にかなっているんじゃないのかなって言ってます。
はあ、なるほどですね。
HTMLやCSSのような宣言型言語である場合は
Webデザインの方が本質的にあっていると。
で我々、僕は特にそうですけどバックグラウンドがJavaScriptのような命令型言語
プログラマー吠えるような人間はおそらくテイルウィンドの方が利にかなっているんじゃないのって言ってますね。
これは結構共感を覚えますね。
テイルウィンド今僕自ら使っててちょっと面倒くさいと思う面もあるんですけど
多分いろいろルールを設定したりとか慣れてきたりすると
多分テイルウィンドの方が結局ユーティリティの方が僕らは使いやすかったりするので
合うんじゃないかなっていうなんとなくの感覚はあります。
はい、すいません。じゃあ最後ですね。
繰り返しますがここには正しいことも悪いこともありませんって言ってますね。
これは適切なツールを適切な考え方に位置させるっていうことですと。
個人的には宣言型のデザインアプローチっていうのは手袋のように私には合いますと。
この秘書の方はですね。
はい、それはジョンの、何ですか。
アダオブウェブデザインっていうのがあるらしいですね。
そういう記事がありますと。
またはEさんのレスポンシブみたいなウェブデザインの伝統のように書いてあります。
これらはウェブのソリューションを操作する方法なんですけど
それが私には合ってるよっていうことを述べて
この記事は終わってますってことですね。
はい、なるほどでした。
今回そのディクラレティブデザインっていうのは
ウェブデザインの話ではありますけど
設計的な意味のデザインっていうニュアンスも含んでるように聞こえました。
基本的にはウェブデザインの方に立脚した話だと思いますけど
なかなか学びというか、共感の多い記事だったなと思いますね。
やっぱり名言型と宣言型っていうところにちゃんと視点を置いてみて
自分がどっちの思想に合ってるかっていうのを考えてから
ツールを選ぶ、フレームワークを選ぶっていうのは確かにいい話だなと思って
あまり意識したことなかったですね。
今回はこっち使ってみようとか
今回のプロジェクトに対して要件がこんなもんだから
例えばデザインはそんなに凝らなくて
とにかく高速にかつ見た目をそれっぽくしてくれればいいよっていうものですね。
よくある管理画面だったりCMSみたいなものを作る場合は
僕らも結構MUIとか入れたりとか
いわゆるCSSフレームワークですかね
サンプルとスラップは最近使わないですけど
何かを入れてそれっぽいものにしてしまうというのはよくありますね。
ほぼほぼ既存のものを作ってそのままやって
そのままアプリケーション作ったりシステム作って
お客さんのニーズに応えていれば別にいいのかなと思ってるらしい。
往々にしてそういうことはありえなくて
結局デザインしていくとCSSフレームワークを拡張しなきゃいけなくなって
途端にハードルとコストがかかるんですけど
なので結果は使わないことも多いということはあります。
30:01
そういうことを加味すると結局
Tailwindの方が柔軟性があるんじゃないかという気もしていて
どっちを取るかというと別の話ですけどね。
思想の話もそうですけど
実際のプロジェクトとか現場のニーズと
スピード感みたいなところも求められたりするので
いろんなものを加味してツールを選ぶのは確かにいいですけど
本質的には宣言型と命令型というところに
分けることができるというのをお方がおっしゃっているという
この言及は割と面白いというか
考えさせられるなとすごく思いましたね。
もし皆さんご自身がどっちなのかなというのを
意識しようとなかったのなら一回考えてみるのは結構いいかもしれないですね。
というところです。
9時半も来てしまいましたので
今日の朝方はこちらで一旦以上にしたいかなと思います。
今日は僕のパソコンが不調でディープエールを使わなかったので
翻訳がかなり変な日本語だったような気がします。
やっぱりGoogle翻訳ってまだまだ課題があるのかなというのも見えて
新たな発見はありましたけどね。
じゃあまた今日から月曜日ですね。
いい週間頑張っていけたらなと思います。
じゃあこれで終了です。お疲れ様です。
