00:12
はい、9月7日木曜日ですね。時刻は昨時33分になりました。
えー、なんかまだ台風13号ですね。
えー、なんか近づいてきてるっぽいので、またですね、雨が降ってくるのかーっていう感じですけど、
まぁ、台風が来た時は皆さんも気をつけていただければなと思います。
おーい、おはようございます。ひめみのきーすくんとくわはらです。
では、本日も早活を始めていきたいと思います。
えー、本日は、そのタイトルが、ちょうどキャッチーなタイトルにしてしまいましたけど、
まぁ、エンジニアというかウェブ業界の推し活という話をしていきたいなと思ったりしてます。
はい、まぁ、エンジニア、特にウェブデベロッパーと言った方がいいかもしれないですけど、
にも、ちゃんと推し活と言われるようなものが僕はあると思っていて、
今、僕もそれをやっています。その中の一つとして。はい。
で、私はですね、Rariot.jsっていうJavaScriptのライブラリが本当に大好きで、
まぁ、今もほぼ、今までもほとんど書いてないんですけど、
もう、なんだかんだコミュニティの投稿だったり、えっと、実際本体のコミットですかね。
とか、更新も追っていたりとかですかね。
あとは、まぁ、僕自身もそのRariot.jsに関して、
C&R研究所っていう出版社から、書籍を一冊で出させていただいた、
出筆させていただいたんですけども、などなどそんな感じで、
結構僕はRariot.jsを推しているんですよね。
で、なんで推しって言っているかというと、あの、仕事で使うことがもうほぼほぼないんですね。
今までの人生で仕事で使ったの、一案件ぐらいしかないんですよね。
一応、全職で一回使ってみて、
あ、違う、二案件やりましたね。今のイメミでも一案件だけやろうとして、
結果的に使わないっていう選択肢になったんですよね。
まぁ、それはいろんな事情だったり、プラットフォームとのその親和性だったりというのがあって、
ウェブの技術でまさかプラットフォームの親和性みたいな話が出るとは思ってなかったんですけど、
まぁ、でもこういうのあるんだなと思いました。
別にそれはRariot.jsに起因する問題じゃなくて、
そもそもそのプラットフォーム固有の問題だったりするので、JSとの愛情が悪かったりとか、
まぁ、いろんな制約があって、ライブラリを入れられなかったっていうので、
まぁ、他のVueとかReactでも多分同じような問題あったかなっていう気はしますけど、
まぁ、その余談はさておき。
まぁ、Rariot.jsを案件で使うことはあんまないなって思います。
それはやっぱり技術者として、今回のプロジェクトとかこのシステム、
作りたい要件とかに合わせると、Rariot別に使わなくていいよねというか、
まぁ、今名前で出ましたReactとかVueの方がいいよねとか、
まぁ、あったりしますよね。
まぁ、その相性もありますし、
このエコシステムの熟成度とか、あとは情報量とかですよね。
何かあったときに軽くグってみて、何か情報出てきて、
これやればいいんだとか、この方法を試してみれば何か直りそうだなとかってあったりするんですよね。
まぁ、そんないろんなものを加味して、僕らは技術選定をしていきますよね。
あとはそのライブラリ自体のメンテナンスですね。
コアチームがどれくらいホットに更新かけたり、
03:00
そういうイシューとかを対応してくださったりとか、
プロリクエストの頻度とかを見たときに、
バックアップ体制がやっぱりしっかりしているようなライブラリの方が、
長くメンテナンスされたり使えるよねとか、
何かあったときに対応してくれそうだねとかですね。
案件固有の問題とか、案件をやっているときに、
このライブラリ、ここら辺バグじゃないの?みたいなところのイシューを投げたときに、
コアチームがどれくらい早く対応してくださるとか、
その辺の加味して、ライブラリの選定とかを僕らはしていくので、
そういうことを加味すると、実はRiot.jsっていうのは、
ほぼほぼ個人、1,2名の方がコアで対応しているに過ぎないので、
やっぱりちょっと使うにはリスクがあるよなっていうのがあるので、
基本的には使わないと。
使わないんですけど、でも僕はRiot.jsを推していて、
それは単純に好きだからです。
これは三つ子の魂100までっていう言葉があるんですけど、
僕それと一緒で、僕がエンジニアになったときですね、
特に社会人になって、エンジニアとしての仕事をスタートしたときに、
一番最初に知ったJavaScriptのライブラリがRiot.jsだったんですね。
その当時は、JavaScriptの3大フレームワークって言うんですけど、
それは旧3大フレームワークで、
ノックアウト.jsと、アンギュラ.jsですね。
古い方のアンギュラ.jsと、あとバックボーンですね。
この3大フレームワークが当時あったんですね。
特にも、JavaScriptのフレームワークで歴史を語ると絶対バックボーンを外せないんですけど、
そのバックボーンが皮切りだったような時代ですね。
ちょっとそこからいろんなフレームワークが出始めたときに、
僕がJavaScriptっていうのを触れ始めて、
ただやっぱりバックボーンもそうですし、
ノックアウトも、あと何だっけ、今言ったらアンギュラか、
アンギュラ.jsですね、の方もですけど、
ちょっと取っ掛かり大変というか、理解するのに結構苦労するなとか、
あとは理解しても、今度は使うところですよね。
使い方が結構大変だったりしてですね。
しかもその時はまだMVなんちゃらっていう議論が割と活発だった時代ですね。
今みたいにMVVMとかっていうのがなくて、
アンギュラ.jsはMVAとかですね、何だっけ、モデルビューエニーだった気がします。
エニーセインかな、何でもいいんじゃないみたいな言い方したりとか、
この辺がまだ議論活発だったりした時ですね。
なので、割とちょっとDOMの操作とJSとのロジックってところが、
割と密度高い時の時代だったんですね。
今みたいにリアクトがはっきりビューしか担保しません。
担保しないって言うとちょっと語弊ありますけど、
今はサーバーコンポーネントっていうのもビューだけじゃないじゃんって話はちょっとあるんですけど、
当時のリアクトですね、まだ0.16とかそういう時代ですね、
まだメジャーバージョンがゼロの時があったんですけど、
そういう時はリアクトは基本的にはビューを担保しますって、
それ以外のところは皆さんまた考えましょうっていうようなライブラリやってますね。
っていう風にビューとモデルとかっていうところがしっかり切り分けられていない時代だったんですよね。
バックボーンとかは特にそうですけど。
やっぱりビューっていうのはあくまでテンプレートの一つだよね。
みたいな時代があって。
なので取っ掛かり結構難かったり、
それだったらですね、今まで通り、従来通りモノリシックにバックエンドのフレームワークを使って作る時代とかあったんですけど、
その時にもっと軽くて、かつ簡単に触れるもんないかなっていうので、
いろいろライブラリを探してたらそのLiott JSってのが見つかったんですね。
06:02
そこからやってみたら確かにすごい簡単で、
かつ僕が好きだったのは入門しやすいし、
既存のJavaScriptの資源が使えるし、
なおかつあまりにもライトだったので、
一本捨てやすいっていうのが僕は結構いいと思ったんですよ。
捨てれるっていう観点、出口戦略があるっていうライブラリが僕は結構いいと思ってまして、
それやっぱりそこに依存しなきゃいけないっていうのは、
割とやっぱりリスクと感じるんですよね、僕としては。
なので簡単に外せて、
でもそこで書いた資源とかを他のライブラリとかにも全然転用できるっていうのは美味しいなっていうので、
僕はLiott JSに惚れたんですよね。
そこからLiott JSが本当に好きになって、
今ではオープンコレクティブっていういわゆる投げ銭のサイトとかシステムがあるんですけど、
そこでLiott JSに毎月何ドルだったかな?
今10ドルだったかな?
で単純に投げ銭をしたりします。
あとは単発とかスポットでウェブパックとかあとパーセルバンドラーとかですかね、
にもなんか50ドルずつその当時なんかボーナスとか入ったので、
じゃあ投げるかっていうのでライブラリに投資をしたりしてました。
で、こういうのを僕は推し勝つの一つだと思ってます。
それは単純に好きだっていうのもあるし、
ずっと伸びてほしいというのもありますし、
特にウェブパックが今はちょっと廃れ始めて、
いろんなバンドラーがまた出始めたんですけど、
その当時はウェブパックが席巻していて、
今でもなんだかんだダウンロード数では世界ナンバーワンなんですけど、
JavaScriptのバンドラーとしては。
とはいえ、そう長く続いてほしいなっていうのと、
僕らは無償で使わせていただいて、
なおかつそれでお金を稼がせてもらっているので、
なんか還元もしたいなっていうのもあるし、
推したいなっていう感触が僕にはあったので、
お金を投げているっていう感じはあります。
僕はこういうのを推し勝つだと思っていて、
同じ感覚は他の方でもあると思うんですよね。
エンジニアの推し勝つって、
いわゆる推し勝つとはちょっと違いますけど、
こういうところを言うんじゃないかなと思ったりしてますし、
推してみ始めるとやっぱりちょっと見方変わるんですよね。
使い勝手とか、機能がどうかとか、
ソースコードどうだったらみたいな観点もあるんですけど、
他の人はこのライブラリどういうふうに見てるのかなとか、
僕はここを別の観点でこういうところが好きなんだよみたいなことを
語れたりするわけですよね。
それに関して技術者の方は技術的なちゃんと批判をしたりとか、
ちゃんと評価をするので、
それはそれとしてもちろん受け取るんですけどとはいえ、
ちょっとキモい発言かもしれないですけど、
リアクトとかビューとかライオットとかもそうですけど、
ちょっとやっぱり擬人化して考えちゃうんですよね。
なんとなくこのライブラリの思想とか性格、
機能とかって言うとこういう人だよなんていうのは
想像無くして評価をする節があるんです。
別にそれは案件の現場でもちろん出さないですけど、
僕の感覚としてはそうです。
なのでそのライブラリの思想とか本当に大好きなんですよね。
擬人化してるからなんですけど。
分かりますか?皆さんないかな?
僕はそういう感覚なんですけどね。
なのがあって好き嫌いっていうのが僕には実はあります。
そんな感じですね。
単純に言うのでお金を投げるっていうのもありますけど、
そういうコミュニティですよね。
いろんなコミュニティ活動にも積極的にスラッグ入ったり、
09:03
発言したりチャットしたりするのもやっぱり好きだから、
せめて盛り上がってほしいなっていうのはあったりします。
とはいえ技術者なので技術的な選定をすると思います。
なので絶対使ってくれみたいなことはかけらも言うつもりはないです。
最適なソリューションを描くために技術選定をするのが
僕らの仕事の一つではあるので。
とはいえ好きあらば。
そしてマッチするなっていう案件がもしあれば
平然と入れたいという思いはあります。
うちの夢見の中で一案件やろうとしては
結局外したって案件も僕がやりたかったから入れたし、
その時の担当者の方が全然やってくださいよというか、
僕がそのコミッターでもあるので
じゃあ安心ですねっていうふうに言っていただいたんですよね。
そういうのもあって入れさせていただいたんですけど、
結果リリース間近なときに
プラットフォームとの親和性が悪すぎて外したっていうのは
悲しい結果になったんですけど。
まあでもさておきそんなことをやりたいと思っていますので。
ちなみにRiot.jsは本当に良いライブラリーなので
お勧めはしておきますが、
クセも正直あります。
ライブラリーなんてクセがないものなんてほぼないと思っているし、
本当にクセがないんだったらそれは多分言語レベルに
帰ってくると思いますので、
それは違うなって気はしているので。
みたいなことをちょっと思っておりましたし、
今後僕もそうやっていろんなライブラリーを今後使わせていただくし、
知っていくと思うんですけど、
その中でやっぱいいなって思うものに関しては
やっぱ長く続いてほしいし、
メンテナーの方々も基本無償でメンテナンスしていると思うんですよね。
ライブラリーとして会社を起こせるレベルになるんだったら
それは話は変わります。
バーセル社みたいに、
あそこはプラットフォームそのものを提供していますよね。
バーセルっていうサービスを提供しているので、
あそこでマネタイザーできているから
そのネクストとかもメンテナンスできていると思うんですけど、
そうじゃないライブラリーとかは基本的には
皆さんが無償で自分の時間を削って
そこに対応してくださっているので、
せめてそこを使ってほしいというか、
そこが自分たちのお金を稼げるというような
プラットフォームになってほしいというのもあって、
お金を投げていくという感じですね。
歓迎の仕方はいくらでもあると思いますけど、
この観点は結構大事だと僕は思っています。
別にお金を投げろという意味ではないですけど、
あくまで利用させてもらっているかつ
そこでお金を稼がせてもらっている方って
たくさんいると思うんで、
その中、じゃあ何か歓迎をしましょうというのは
やっぱり大事だよなと思ったりしますね。
作者だけの関係ではなくて、
何かしらの恩返しをするというところですね。
みたいな、今日はちょっと思いながら
お話ししてみたかったという感じですね。
はい、ちなみに僕今は興味あるのは
Riot.jsよりも、
まだJSの話ばっかりでごめんなさい。
今はですね、Quickというフレームワークです。
QWIK Quickというフレームワークがありまして、
名前の通りですけど、
とにかく速度が最優先みたいな
フレームワークがあるんですよ。
JavaScriptの。
めちゃめちゃ速いです。
とにかく速いです。
ただ、闇と言わないですけど、
ビルドした後の吐き出された行動を見ると、
結構力技だなってすごく感じました。
それはその代わりに速いよねって思います。
初期レンダリングとか爆速なんですよね。
他のライブラリーの爆速とか
気にならないぐらい速いです。
12:00
ただし、そういうことをやってるのかみたいな、
いわゆるハイドレーション周りとか、
その辺のところが、
力技というかテクニックをやってるなって
すごく分かるので、
それをどう評価するかって感じですけど、
僕は速度中の人間なので、
速ければ速いに越したことはないような人なんですね。
とはいえ開発者なんで、
開発者の一番時間を食うのは、
ソースコードのリーディングですよね。
読むことに実はエンジニアって一番時間を使うと
僕は思ってて、
そうすると過読性が高くないと
チームで開発するのに他の人の時間を奪うと。
人の時間を奪うっていうのはかなり悪だと思うので、
人の時間は有限ですよね。
かつ、ビジネスはちゃんとお尻が決まってて、
なるべく早く出せるに、
それは越したことはないので、
人の時間を奪うライブラリーは
基本的なビジネス的にもアウトだと思っているので、
その意味でQuickも案件ではお勧めしないです。
ただ、リリースした後の
ユーザーの時間を奪わないっていう観点でいくと
Quickはかなり強いので、
どこの時間を削れる、
その代わり犠牲として
どっかで頑張らなきゃいけないっていうのは
それはトレードオフだと思うんですけど、
そういうビジネス観点はもちろんありますけどね。
僕はやっぱりパフォーマンスが大好きなので、
Quickっていうのにも興味を持ってるっていう感じです。
この観点はいろんな観点ありますけどね。
というので、
余談をさせておき、
今日の朝活はこの辺で締めていきたいと思います。
あと皆さんもどんな推し活、
もし自分も推し活、
エンジニアとしての推し活やってますよって方いらっしゃって
ツイートしたりコメントしていただけたらすごく嬉しいです。
この辺共感あれば
いろいろ一緒にお話ししたいなと思ってますので、
もしあれば教えていただけたら嬉しいなと思ってます。
では、ダラダラとしゃべりますが終わっていきたいと思います。
また明日、金曜日ですけど
ダラダラとしゃべっていきたいと思いますので、
興味あればまた来ていただければなと思います。
今日も一日頑張っていけたらなと思います。
終了します。
お疲れ様でした。
