00:06
7月13日水曜日、時刻は昨日もありました。
大にくの東京は、今日はライブになるらしいですね。
はい、おはようございます。ひめみのkeethことくわはらです。
では本日も朝活をやっていきたいと思います。
昨日は完全にレボして忘れてしまいましたって感じですね。
はい、申し訳なかったです。
では今日も朝活をやっていきたいと思いますけど、
今日読む記事はですね、前回?前々回?前々回ですね。
読んでたフロントエンドウィークリ東京さんの記事2つの中から、
10個の中から2つ読むんですけど、
今日はそれのまた違う2つの記事を読みたくなったので、
読もうかなと思います。
はい、ダイツンですね。おはようございます。いつもご参加ありがとうございます。
今日はですね、今日読む記事は2つですね。
Re-evaluating technologyでテクノロジーを再評価するときっていうのと、
もう1個、for trade office when designing navigation menusと
実装する際の4つのトレードオフについて紹介しているっていう、
この2つの記事を読んでいこうかなと思っております。
技術の再評価でもしかして読んだかな?
なんか読んでない気がするんですけど、
ちょっと読んでいこうかなと思っています。
では行きましょう。
ほーい。
では行きますね。
Re-evaluating technologyからです。
意思決定には多くの重点を置いていますと、
正しい決断をすること、
決断する前に全ての正しい要因をまず評価をすること、
しかし意思決定の再検討についてはあまり語られることが実はないですよね、
というふうに言っています。
正しい決断とかその決断の要因の評価、
この辺に関しては確かに結構議論されることはあるんですけど、
意思決定を再検討することっていうのは確かにあんまり
述べられているものって見たことないかもしれないですね。
おそらく人間には過去の決断を固定観念として扱う傾向があるのでしょう。
テクノロジーの評価に関しては少なくもそれは確かだというふうにおっしゃっていますね。
一応エヴァリエイティングテクノロジーっていう
テクノロジーの評価自体の記事もこのようなリンクに載っていますね。
後ほどこの記事自体のリンクをスイートしますので、
その中から追ってもらえるというのかなと思います。
今回の記事はリバリエイティングじゃなくてリエヴァリエイティング、再評価ですね。
筆者もその傾向があるとおっしゃっています。
以前マークという人とPHPで書かれたもの、
おそらく私が書いたものだと、おそらく私が書いたと言うから
どこに書いたものなのでも覚えてないかもしれないですね。
について話していた時に
PHPが優れて言語ではないことは知っているけれど
…みたいなことを言ったのを覚えているらしいですね。
マークはそのことについて正しく私を非難しましたと。
PHPは昔は良くなかったけど今は飛躍的に進歩した言語です。
しかし私の言語に対する認識はそれに合わせて更新されていなかったのです。
03:00
これは良い議論ですね。
PHPは僕は7からだいぶ良い言語になってきて
8になってさらにモダンになったなというのは本当に思っていますね。
厳密に言うとちゃんと書いてないんですけど
アップデートだったり文法的なものとか新しい機能であったりとかいうのは一応追ってますね。
こう見ると確かにPHPってもうだいぶモダン言語で
私としてもだいぶ再評価してもいいなという本気で思っておりますね。
昔は本当にひどかったと思います。
ホッタンがそもそもプログラミングするために書かれた言語ではなくて
ウェブページのちょっと動的にするというか変更するためだけのものだったので
あくまでHTMLをベースにそれの手伝いをするみたいな言語だったので
それでアプリケーションを作るというのはそれはつらい話だったんですけど
今は全然もうアプリケーションに使える言語として
全世界でも使われてるんじゃないかなと思ってますね。
でもここの話で良いのは
自分がもうすでに知っていること、基地だと思っているものを
本当に今どうなのかという再評価をすることというのがやっぱり主眼にあるので
これはすごく大事だと思ってますね。
やっぱり技術っていうのは日々に進捗で進んでますし成長していきますし
過去にあったものでもずっと今も使われ続けてるってことは
今もメンテナンスされてるはずで
もちろん機能拡張だったり進化してないものもありますけど
してないかどうかは見てみないとやっぱりわからないのでね。
というので一回自分の持っている知識の棚下ろしをして
それを再評価をするっていうところが結構重要だという形ですね。
この例としてPHPを出したのは確かに結構面白いですけど
よくあるネタなので分かりやすくて良いなと思いました。
で、戻りますね。
私は過去に調査したんですけど
しばらく使ってないとかしばらく触ってない言語
ツールとかフレームワークについて考えるとき
いつもこの教訓を心に留めておくようにしています。
こういうことをしっかり言ってくれる知り合いとか
友人のエンジニアがいるっていうのは本当にいい話ですね。
でまた、アンディという方ですね。
アンディという方がいて
これをテックツールのカルーセルと呼んだりしているそうですね。
テックツールカルーセルってまたその別のリンクも張ってますね。
ちょっと一瞬だけ見ます。
ザ・テックツールカルーセルというもので
記事としては今年の5月29日に書かれた記事ですね。
割と短い記事なので
今日のこの記事が長いので
もしあれだったらテックツールカルーセルも
後ほど時間が余れば読んでみようかなと思います。
カルーセルっていうのは
ゲーム番組で獲得できる商品を表示するもののようなものだと言ってます。
カルーセルっていうのは
私や一緒に仕事をしているチームやクライアントにとって
実際に使えるツールになるためには
十分熟成されたと思うまでそこに置かれることになるのです。
これちょっとカルーセルの中身とか記事を読まないと
コンテキストがわからなかったですね。
またカルーセルっていうのは
循環型でありツールやテクノロジーは再評価のために戻ってくるのです。
06:02
ああそういうことね。
そういう意味のカルーセルっていう風に評価してますね。
一度目の前を通り過ぎたテクノロジーっていうのは
ベルトコンベアに乗っているようなもので
一度評価したらもう二度と評価し直すことはありません。
再評価をしない限りはずっと流れ去ってしまうっていうのは
確かにそうだと思いますね。
しかしこれは決して終わりのないプロセスではありません。
ある時点から
ある時点からあるテクノロジーは戻る価値がないことが
明らかになるのですと言ってます。
カルーセルに入れたままにしておいて
やっぱりダメだったということで外すこともありますから
本当に有効な戦略だなというふうに思っていると言ってますね。
なるほどですね。
続いて読んでいきましょう。
例えばですね。
クリプトボリックに関連するものを見てみましょうと。
クリプトボリックってなんだ。
僕はクリプトボリックっていうものを知らないので。
それだけで調べても出てこない。
壁画か。
壁画のことを意味するものですね。
10年以上経った今でもブロックチェーンというのは
問題を解決するための手段であることに変わりはありません。
モリーホワイトという方がおっしゃっているように
まだ黎明期とも言えませんと。
まだ黎明期とは言えませんということを書いた記事もありますね。
It's not still the early daysって言ってますけど。
そこに書いてあるもので見てますと。
いつまで初期なんだと。
あらゆる意味で非効率的な技術を
後付けで正当化しようとする見え過ぎた試みではない
ブロックチェーン技術の実際の応用を誰かが考え出すまで
どれだけ待つ必要があるのでしょうかと。
プルフオブワーク型のブロックチェーンの初期を脱するのを待つ間か。
私たちはどれだけ待機中に汚染を送り込むことを
正当化しなければならないのでしょうか。
これは技術に関してよくある話ですね。
いつまで初期なのかっていうところを
ちゃんと定義するっていうのはいい話だと思いますけど
往々にして定義はされないし
それに対して批判も結構くると思いますけどね。
ブロックチェーンは確かに今の
ホットな話題と言いますか
前提としては面白いなと思いましたね。
あれ自体は確かに10年以上前から
技術的にはすでに確立をしていて
今も進歩はしてるんですけど
けどなかなか使われなかったり
今やっと流行り始めたっていう感はありますけどね。
これについていつまで初期なんだって言われたら
もうとっくに初期じゃないでしょって思ったりはします。
では話をウェブの話に戻しましょうか。
ノラン・ローソンっていう方がまた出てきますけど
ノラン・ローソンは最近シングルページアプリの
バランスが崩れたって感じてるなっていう風に
09:01
洞察に満ちた記事を書いてるそうですね。
これもまたリンクが貼ってますね。
今日もリンクだらけですね。
The balance has shifted away from single page apps
という風に書いてますけど。
この中で述べていることがあって
私は時代の流れが同じように変化していることを感じます。
とはいえノーランも私も
ブラウザーがどのように進化してより良くなっていくかに
常に注目をしています。
ノーランがフォローアップの投稿で書いてるようにと言ってます。
ノーランがフォローアップの記事をまた別で書いてて
またそのリンクも貼ってますね。
その中で書いてあるんですけど
私が言いたかったのは
SPAを使う唯一の理由が
ナビゲーションを速くすることであるなら
それはもう見直す時期が来てるのではないかということです。
と言ってますね。
なるほどです。
SPAの一つのメリットはシームレスだというところです。
画面フラッシュもしなくて良くて
ユーザー体験が良くなるというところが
一つの魅力と言いますか。
利点なんですけどそれしかないのであれば
別にSPAを使う必要もないんじゃないかというのは良い話だと思います。
割と高速化してできたりする話もありますし
改めてNPAによる
キャッシュ戦略も全然すれば
SPAと同等レベルのスピードなんて全然出ますからね。
定期的な再評価が必要な技術の最も良い例は
おそらくワールドウェブでしょう。
ウェブは存在期間中より独自性の高い
他のテクノロジーによって改善されてきたように見えます。
フラッシュはウェブよりも優れていました。
ウェブよりも優れていました。
フラッシュにはベクターグラフィックスやスムーズなアニメーション
ストリーミングビデオがありましたが
ウェブにはそのようなものがなかったのです。
しかし時が経つにつれてウェブが追いついてきました。
フラッシュはウサギ、ワールドワイドウェブはカメだったと。
このウサギとカメの話題ってまさか海外でも使われてるっていう
僕今初めて知ったんですけどね。
このネタって世界的に鉄板なんやな。
もともとこの話自体が海外初でした。
僕が覚えてないんですけど勝手に日本初と思ってたんですけど
これ海外だったっけ?
英語の記事でウサギとカメっていう例を初めて見たので面白かった。
余談です。
最近の記憶ではウサギの役割はネイティブアプリがになっていますよと言ってます。
最近の記憶ではウサギの役割はネイティブアプリがになっていますよと言ってます。
ネイティブアプリが…
ウェブの進化ってネイティブアプリ開発によってきてるってのは僕もずっと思ってて
コンポーネント化っていうのはまさに
ネイティブアプリの開発と一緒ですよね。
12:01
ウィジェット的なものだったりとかと似てるなってのもありますし
SPAなんてまさにそうですよね。
アプリは一応ページ遷移しますけどフラッシュすることはまだないし
あとはPWAっていうのもあったりするので
よりネイティブ感のある操作感を
ウェブで実現するっていう技術がどんどん生まれてきているので
そうなんですよね。
ネイティブアプリに似ているっていうふうに僕も思っていたりします。
戻りますね。
Twitterのデザインチームで複数のプラットフォーム向けにデザインやビルドを行っている人と話したことがあります。
彼らはウェブに不満を抱いていました。
iOSやAndroidのような
完全な機能性を感じられなかったのです。
その不満は当時は全くもって正当なものでした。
しかしその後彼らはその判断を見直したのでしょうかと。
見直したんですかね。どうなんでしょうね。
サービスワーカーとかJavaScriptのネイティブAPIとか
CSSでできることの驚異的な増加。
そして何よりブラウザー間の相互運用性が
どんどん向上しているということが重要ですよと。
新しいウェブ標準のユニバーサルサポートというのは
かつてないほどの速さで到着しています。
これは本当おっしゃる通りで
全くもって完全同意ですね。
なのでウェブって言っても
昔ながらのウェブ
単純にページとかアプリケーションを表示するだけのもの
というわけではなくなってきているし
どんどん機能性であったりとか体験が上がってきていますので
この辺は再評価するのは絶対ありだと思いますね。
僕らウェブ開発者の人たちは
この辺はたぶん理解しているし
日々日々感じているところだと思いますけどね。
続きます。
ブラウザというのは依然として疑心暗鬼で
ブラウザのネイティブ機能よりもサートパーティー性のライブラリを信用したがります。
彼らは過去にそれらのライブラリについて
決断を下しました。
ブラウザのサポート状況も過去に評価しました。
その決断を改めて見直してほしいというふうにこの人はおっしゃっていますね。
しかし惰性というのは
言葉通り惰性ですね。
非常に強い力を持っています。
それが最良の選択ではないとしても
過去の決断に骨折することは全てを再び評価し直す努力をするよりも
簡単なことだと言っています。
そうなんですよ。再評価ってエネルギー使うんですよね。
あと自分が信じていたものを
意外ともう一回疑わなきゃいけなかったりするので
怖かったりするんですよね。
こんな言葉があります。
強い意見弱い意見ですね。
私たちは前者には非常に得意ですけど後者はかなりの苦手です。
というふうに言っていますね。
ウィークリーヘルドなので
厳密に言うと弱い意見というよりも
実行というかアクションとかそれに近いようなことだと思います。
先日ある同僚と
webとネイティブアプリで提供されている
オンラインサービスについて話していた時のことです。
15:01
彼は自分の携帯電話でネイティブアプリを見せながら
いいアプリじゃないと評価しました。
どうしてwebサイトをスマホに追加しないのと尋ねました。
あのねと彼は言いました。
webサイトは遅くなるんだよと。
彼はこれをテストしていませんでした。
過去に携帯電話でくだらないwebサイトを扱ってきたことで
彼はwebはネイティブアプリよりも本質的には悪いと考えました。
しかも遅くなるんだよというところが悪くなるという
根質的な評価ポイントだったらしいので
これも結構見直すのは全然ありだと思いますね。
この特定のサービスで行っていたことは
ネイティブの機能を必要するものではなかったにも関わらず
この人はネイティブアプリよりwebは本質的に悪いと考えるようになってしまった。
しかし今ではそれが定説となっているようですね。
ネイティブアプリの方がwebよりも優れているのですという
定説ではなっています。
そしてどんなことをしていますかと。
かつてそれは真実だったでしょうと。
ここしばらくはそうではありません。
少なくとも技術的な観点からは現在はそうではないよと言っています。
たとえブラウザの技術がネイティブアプリと同等になったとしても
人々が以前に形成された信念を見直すように説得できない限り
それは重要ではありませんと言っています。
技術的なことは簡単です。
技術についての意見を見直すように仕向けるのは難しいことです。
それが根本的に難しいと言われているところですよと言って
この記事を終えられています。
みんなの固定からネイティブタイプを崩すというのは
ものすごい大変ですし
自分自身もネイティブタイプを持っていると
そもそもそこの観点にたどり着かないこともあったりするので
こうやって記事にして一回疑ってくださいということを
訴えてもらえるのはすごくありがたいことですね。
特に一番身近であるwebというところの再評価をするのは
本当にありがたいと思います。
でも言われて確かにそうですけど
なんとなくwebよりネイティブアプリの方が優れている
という風に感じるのは僕も思っていて
おそらくですけどネイティブアプリは端末のAPIとか
ネイティブのAPIにアクセスできるというのは結構大きいんじゃないかなと思っていますね。
昔はwebアプリケーションをスマホで開いても
webアプリからカメラを開くことはできなかったので
今でもできるようになったりそういうツールも生まれたりしますけど
webからジオロケーションにアクセスできたりするようになったりとか
割とwebのネイティブ機能でも
そこそこネイティブアプリに近いものも大体生まれてきたりするので
改めて再評価するのはあると思いますね。
もちろんネイティブアプリと
webアプリで同等のスピードとかパフォーマンスを出せと言われると
そこはきつい話はあるんですよね。
どこまでいったってネイティブの方が早かったりするのは事実でし
webアプリってそもそも
ブラウザのメモリーの限界もあったりしますので
難しい問題はありますけど
じゃあ全部が全部そうかというとそういうわけではなかったりするので
再評価をするのはありだと思いますし
ブラウザのネイティブアプリのネイティブAPIとかの機能を使って
アプリケーション開発ができるのであれば
18:01
サードパーティーのものに頼らなくても本来良くなっているとは思ったりしますし
そこはやっぱりネイティブの方が良かったりするところはありますよね。
ブラウザに特化した機能があったりするので
それをサードパーティーのJavaScriptで埋め込んだものと
どっちがいいんだろうというのは再評価をするのは全然ありだと思います。
というところでとても知的に問われた記事だったなと思いました。
もう一個読もうと思っていた記事ですね。
For trade-offs when design navigation menuですね。
ナビゲーションメニューをデザインするときの4つのトレードフについて
というところですけど
めっちゃ長いのでこちらは読むのを諦めます。
後ほどTwitterで飛ばします。
残り時間で読めそうなのがもう一個ですね。
こっちについてちょっと僕は見てみたくなったので
すいませんが変更します。
他にもリンク貼ってあった記事たくさんあるんですけど
the balance has shifted away from SPAsというところと
more thoughts on SPAsですね。
さっきの記事のいわゆるアンサーブログ的なやつですね。
という記事2つもありますけど
これもツイート数多くなりますけど共有します。
皆さんの方で見ていただけると思います。
じゃあいきましょう。
the tech tool carouselですね。
最近オタク仲間にカルーセルと呼んでいるものを説明したので
それについて書いてみようと思います。
オタク仲間って言ってるけど
翻訳がオタクって言ってるが
フォローナーって言ってるんでオタクです。
私はウェブというものを初めて何年も経ちますが
多くのゲームチェンジャーが現れて
漁っていくのを見てきました。
それは全て非常に循環的で予測可能だと言ってます。
私は自分の出す作品に対して
我慢ができないほど高い基準を持っているので
犬がソーセージの列を持つ肉屋を追いかけるように
外国人の例え話
知らなかったり理解できないものがあったりするので
面白いな。犬がソーセージの列を持つ
肉屋を追いかけるように
新しいツールを追いかけることは非常に
相入れないものなんです。
この人は基準が高いんですよね。
自分の持っている作品に対しては
こだわりを持って高い基準を持っているので
新しいツールを追いかけることとは相入れ難い。
だから定期的に新しいツールを
メリーゴーランドに載せて様子を見ることにしています。
でもちゃんと評価はしていることですね。
メリーゴーランドって言っているけどカルーセルのことですね。
このメリーゴーランドっていうのは
ゲーム番組で景品が当たるようなものです。
そのツールは私や一緒に仕事しているチーム
もしくはクライアントにとって実際に使えるツールになるには
十分な成熟を遂げたかと私が思うまでは
そこに置かれることになるんです。
この人の中でもう使えるゴーでいいなと思うまでは
基本的には置いておくんです。
21:01
カルーセルに7年以上費やしています。
結構時間かけたんですね。
リアクトを使うかどうかってところまで。
割と皆さん一回リアクト使ってみて
使って評価をしようってところだと思うんですけど
この方も多分一回使ったんかもしれないですね。
リアクトは初期リリースもだいぶ前ですからね。
確か7年くらい前かな?8年くらい前かな?
今年が新卒で社会人になったばっかりの頃に
こんなのあるんやと思いながら全然触らなかったんですけど。
余談でした。
カルーセルに載せたままにしておいて
結局役に立たないことが判明したので外すというツールもあるので
これは本当に便利な戦略だと言っています。
ギャッツビーがその良い例であると言っています。
この人はギャッツビーを外したんですね。
あのツールが巻き起こした耐えがたいほどの古代宣伝というのは
それが役に立たないことを示すちょっとした兆候でした。
最も宣伝されたツールが現地の世界では
全く役に立たないということはよくあることです。
私のカルーセルに眠っている間に
最も福音主義的な人々にそのようなことをさせておけば
私は多くの時間と率直にエネルギーを節約することができます。
アリアダプターじゃないですけど
ラガードだっけ?
新しいもの大好きな人たちがたくさんいらっしゃるので
その人たちの記事を書いたりとか
やってきたみたいな知見を後で見る方が
効率的に評価できたりすると思います。
続けていきますね。
親愛なる読者の皆さん
実は私はコーディングを楽しんでいるわけではないのです。
コーディングによってできるようになることは楽しいのですけど
くだらない小さな単語や数字、不当点を書く作業は
楽しい経験ではありません。
それは僕らも本質的にはそうですよね。
私はコーディングが出力するものを手に入れたいだけなのです。
私がコーディングを始めたのは、私の仮説によると
開発者が目をつぶって私のデザインワークを
構築することが多かったため
主に悔し紛れにHTML、CSS、JavaScriptを習得したのです。
だいぶこの人クセがありそうだな。
それも別に嫌いじゃないです。
だからカルーセルが存在するのですが
カルーセルを外せるツールというのはあまりありません。
カルーセルが外れてもまた元に戻るものもあります。
この人はちゃんと外したものも再評価しているのですね。
それは素晴らしい話です。
そこは懸念に思っていたのです。
で、Tailwindが実はその例だったらしいですね。
数年前クライアントプロジェクトで使ったのですが全然役に立たないと感じました。
でも今ではほとんどのプロジェクトで使っています。
なぜなら既存のHTMLとCSSを細かく味付けするために
必要なUTTクラスだけを生成するという
その最も熱心なファン、そして作者が
耐えがたいことの嫌なヤツであることがダメなのです。
本当に面白いなこの人。
そうなんや。
24:02
Tailwindのファンともしかしたら
開発者自身が耐えがたいことの嫌なヤツ。
この人とは合わない。
とにかく今はですね。
LinuxとAtroというものが大騒ぎになっていて
カルセルに乗るのを楽しんでいるから
こんなことを書きになったらしいですね。
彼らはGatsbyになるかそれとも11T
あの日の出来の良さに史上最短でメリーゴールドに乗ることになるのか
時間が経てばわかるでしょうと言っています。
11Tというのは
皆さんご存知かもしれないですけど
世界的に使われている静的サイトジェネレーターの一つです。
もちろんGatsbyもそういうものにありますし
Atroもそういう静的サイトのジェネレーターとして使うという例もあります。
Atroは僕全然触ったことなくて
最近名前を初めて知ったからですね。
Linuxはもちろん知ってたんですけど
全世界がやっているサーベイの
JavaScript版ではLinuxというのが結構出てきてたので
注目はしてたんですけどね。
一応Atroというのがあったりするそうです。
一旦この人も出来の良さに最短で11Tで
この人のご自身のメリーゴーランドに載せたらしいです。
結構触ってみたんですけど
11Tかなり良さそうだったんで割とオススメです。
評価してみて下さい。11T名前通り11ドットなんちゃらみたいな感じだった。
というところでした。
この記者の方がくてがって良かったんですけど
割とちょっと僕親近感湧いたので
この人のブログを追ってみようかなと思いました。
RSSのフィードもありましてツイッターのアカウントもあるそうですので。
今日は30分になりましたし
こちらで朝方終了しようかなと思います。
本日もちょっとグダグダやったんですけども
ご参加いただいた方々ありがとうございました。
また明日も技術的に記事を見つけたら読んでいこうと思いますが
見つけられなかったら
今日リンク貼ってあった
Balance has shifted away from SPA
SPAのバランスが崩れていったという話と
この辺をちょっと読んでいこうかなと思います。
もしくはまたウィークリーニュースを一個一個読んでいくかもしれないですけど
何かしら読んでいこうと思うので
もしご興味がある方はまたゆるりと参加いただければなと思います。
では本日のあった方は以上にしたいと思います。
今日も一日頑張っていきましょう。お疲れ様です。
