00:05
はい、みなさんこんばんは。株式会社ゆめみでチャレンジ取締役をしておりますキースこと桑原です。
Web 業界のなんでも雑談室へようこそ。この番組ではWeb 業界に関することや様々な雑談などの情報を発信していきたいと思います。
第103回は、技育祭 2021 で登壇した内容を改めて喋る、というタイトルでお話をしていきたいなと思います。
タイトル通りというか、もうこれ以上でも以下でもないんですけども、
3月11日から13日ですね。3日間にわたってですね、株式会社サポーターズというところのイベントで技育祭というものがあります。
技術者を育成するお祭りという感じ3文字をとって技育祭です。
この技育というのが、いわゆるプログラマーとかの
それを継承することで、ギークという言葉があるんですけど、
と掛けているところで、なかなかネーミングセンスがあって素晴らしいなと思ったんですけど、
昨年もイベントやってたらしいんですけど、全然知らなくてですね、今年情報を仕入れまして、
速攻でスポンサーとして会社で夢見者でして、登壇をもらって私も喋らせていただいたって形ですね。
私の喋ったタイトルはですね、ボダンフロントエンド技術の追い方というところですね。
それにOSSの魅力を添えてという話題をつけたんですけども、
実際問題というか本来的な話をすると、フロントエンドに特化した内容ではあるんですけど、
別にフロントエンドエンジニアだけの話ではなく、別にサーバーサイトだろうがインフラだろうが、
その他諸々に関しても結構通じる話なんではないかなと思っておりますし、
冒頭もそういう話をしてますけども。
やっぱり緊張したりとか、その場での喋った内容の補足ではないですけど、
一応ノートもそういう補足情報のノートを今書いている途中なんですけど、
とは別で、これの登壇内容を改めて喋りたくなりましたって感じですね。
ちょっとブラッシュアップを改めて自分でもしたって感じなので、
先にそれをやってから本番喋れよってお話ではあるんですけども。
というところをですね、もうすでに神々なんですけども、
早速喋っていきたいかなと思っております。
本番の内容は多分YouTubeでまた配信されると思うんですけど、
一回音声的に、ポッドキャスト的に聞きたいなという方も多分いらっしゃるのかなと思っているので、
需要があろうがなかろうが、僕も喋りたいので喋っていくっていう感じです。
聞いたことある本番参加された学生の方は重複すると思いますけど、
少し多分内容変わるかもしれないし、
ちょっと新しい情報を出せるかもしれないです。
この後の僕が喋るかもしれないんですけど、
ギリギリ的に喋っているので、
全く同じだったら申し訳ないですけど、ご了承いただければなと思います。
じゃあ早速喋っていきたいと思います。
余計長くなりました。
03:00
というところで、若干過去を振り返っていきましょうっていう話からスタートしたんですね。
昔のフロントエンドっていうと、いわゆるNHTMLとCSSとJavaScriptですね。
この三つがとりあえずあればフロントエンドだねっていう話をしてました。
ゲームセンターと昔だって普通にフロントエンドって区切ってたわけでは、
もちろんないと言っている語弊がありますね。
あったかもしれないですけど、基本的にはなかったんですね。
今見た三つにプラス、JQueryを使っていればフロントですねみたいな話だったんですよ、昔はですね。
それが現代に近づくようになって、どんどんどんどんカテゴライズというか、
細分化していって特化していったものがあるんですね。
JavaScriptも素のJavaScriptを書くのではなくて、オルト・ジェーズと言われて、
JavaScriptに変換するための別の言語みたいなスーパーセットを使っていくみたいなのがありましたし、
CSSも同じですね。オルト・CSSと言われるもの。
コンパイルしたらただのCSSに戻るんですけど、それをもっと拡張した書き方ができるものっていうのができた。
オルト系と言われているものもあれば、いわゆる静的コード解析と言われる、
リンターとかフォーマッターと言われるものも一番たくさん生まれたんですね。
現代だと多分ESLintとかStyleLintとかが基本ベースで、
あとフォーマッターでするとPrettierとか、この辺がベースとなりますね。
昔はJSヒントだったり何やら一般あったりしたんですけどね。
だいたい今はもうESLintでほぼ集約したのかなと思います。
ちなみにTypeScriptにはTSLintっていうものがあったんですけど、
こちらもESLintに集約するってコアチームの方が言ってたと思うので、
ESLintを使ってれば間違いないんじゃないですかってところですね。
あとはバンドラーとかですね。
今の現代のフロントエンドの開発だと、
JavaScriptとかCSSとか静的な他、画像とかいっぱいあるので、
いわゆるアセッツって言われるファイルですけど、
この辺って昔は一個一個全部EHTMLの中に自分で記述してインプルートしてたんですよ。
インポートか、感じですね。
わざわざ一個一個やってたので、名前のバッティングする可能性もあるし、
順番によってほげほげみたいな話もあって、
いやよくわからんじゃんって話になるので。
かつやっぱり読み込むファイルが多ければ多いほど、
ブラウザーはそれを最終的に解析してレンダリングしていかなきゃいけないんですけど、
その処理も増えるし、そもそもネットワークのIOも増えるわけなんですよ。
パフォーマンスが悪いというところで、
一つのガスンとバンドルして、
バンドルって一つのファイルにガッチャンコするって意味なんですけど、
そしてそれをHTMLは最終的にそのガッチャンコしたファイルだけを読み込めばいいみたいな、
開発が今のフロントエンドなんですね。
そういうためのツールとしてはウェブパックとかロールアップとかパーセルとかもいっぱいあるわけなんですけど、
だいたいウェブパック使ってもいいんじゃないのって話ですね。
現代のほぼデファクトスタンダードのウェブパックです。
そういうのがありますよって感じですね。
昔はそれと比率と言いますか、似たようなものとして、
グランドとかガルプとかいわゆるタスクランナーって言われるものですね。
そういうものも昔はあって、
今は別に使われてないわけではないですけど、
ほぼもう枯れてきたっていうか、あんまり使われなくなったなっていう感じはありますね。
本来そのガルプとかもそうですけど、
別にタスクランナーなのでバンドルはその中の一つとしてオプションに入ってくる感じです。
06:02
タスクランナーはどういうタスクをさせるのかっていうのをこちらが命令していかなきゃいけないので、
その命令群の中にバンドルっていう命令があるんだったらやってくれますけど、
こちらが命令しなかったらやってくれないので、
ちょっと役割が違うなっていうところがありますけど。
で、次ですね。
あとなんだっけ。
今ですがね、今ではCSSをJavaScriptの中で書き込んでしまおうっていう流れもあって、
いわゆるCSS in JSって言われたりする技術といいますか、考え方が今あるんですね。
それに基づいたライブラリーとしてStyled ComponentsとかEmotionとかJSSみたいなライブラリーもあったりします。
あとはUIライブラリーですね。
現代のJavaScriptのフレームワークっていうかライブラリーですよね。
今はフレームワークを使うよりも多分UIに特化したライブラリを使ってフロントエンドを開発するっていうのがほぼデファクトなんですね。
名前は聞いたことあるかもしれないですけど、
ReactだったりとかVueだったりとか、あとSvelteとかですね。
あとはAngularとかもあったりしますけど、この辺とかですね。
あとはTestですね。
フロントエンドにもやっぱりちゃんとTestのフレームワークとかライブラリがたくさんありまして、
現在だとほぼほぼJestっていうもので一択だと思います。
ほぼテストに使いたい機能とか欲しい機能が全部ここに集約されている、
その素晴らしいフレームワークなんですよ、Jestっていうのは。
今はこれを使うのが当たり前なのかなと思います。
それにSnapshot Testっていうあれですね。
いわゆる画面までテストするわけじゃないですけど、
でもパシャッとその時のソースコードを保存しておいて、
それのペースにテストしてくれる。
リグレッション的にも使うこともできなくはないよっていうのがあって。
そういう風にEngiumっていうのがあったりしますね。
Engiumって読むのかEnzymeって読むのかちょっと僕は把握しないんですけども、Engiumって勝手に読みます。
あとはそのE2Eテストですね。
エンドトゥエンドテストって言われるもの。
それのテストフレームワークもいっぱいあるんですよ、今って。
あるんですけど、よく名前聞くのがなかったのがテストカフェってやつですね。
僕はそれとは別にコードセプトJSっていうものがあって、僕はそれを使うことも結構ありますね。
ただあんけいにE2Eテストまでやるかっていうとそうでもなかったりするので、
その辺はもし使うときになったら勉強するでもいいですけど、最初に知っておいても損はないかなと思います。
こんな感じですね。
あとはですね、現代だとSPAを作ることが圧倒的に多いと思います。
なので、フロントエンド側でもちゃんとデータ、状態の管理をしなきゃいけない。
そのためですね、ステート管理するためのストアっていうライブラリーがあるんですよね。
ストアライブラリーもたくさんあって、リダックス、ビュックス、リコイルとかRXJSとかいっぱいあるんですよ。
あとはCICDですね、継続的デプロイメントがあるんですけど、そういうサービスもあって、
フロントエンドでも結構そういうのを使うようになってきたなというのは印象としてあります。
有名なところで言うと、サークルCIという名前が出てきたりとか、私は結構AWSを使っているので、AWSのアンプリファイとかコードパイプラインとかあったりしますね。
あとはジェンキンスとかも、ちょっと笑っちゃいましたけど、フロントエンドである可能性はありますね。
09:01
フロントエンドの環境をどうやって管理するかというのもありますし、デプロイ先の環境とかもあったりするので、
ちなみにジェンキンス自体は全然素晴らしいツールで、今もバリバリ使われていると思いますね。
AWSというワードが出ていたので、AWSのサービスの名をちょっと出すと、アンプリファイもそうですし、S3というやつもそうですし、
クラウドフロントとか、さっき言ったコードバイプライン。
コードバイプラインはちなみにコードコミットとコードビルドとコードデプロイの3つを1つにしたものがパイプラインというやつですね。
他にもいっぱいありますよね、AWSのサービスって。
なのでそれがフロントエンドでも全然今は含まれてもおかしくないだろうというのがよく出ますね。
あとラムダとか、あとAPIゲートウェイとか、その辺もそうです。
その辺もフロントエンドとは言わないですけど、知っておいて損ないというか、使えた方がいいよねというものとして僕は名前を挙げておきます。
他にはそれ以外いろいろカテゴライズ難しかったものとして、グラフQLとか。
グラフQLの後のライブラリーとして、アポロとか、いろんなグラフQL-ホゲホゲみたいな名前のライブラリーもたくさんあったりはします。
あとBFFとか、あとアトミックデザインとかですね。
これは設計思想の話です、アトミックデザイン。
でもこれはフロントエンドなら名前一度は聞いたことあるし、どんなものかっていうのは概念ぐらいは知っておいてほうが話すときにもいいのかなと思いますし、
あ、知らないんだっていうので、プロジェクトによってはちょっとアタイン話されるっていうか、されないかもしれないですね。
今現代そんなアトミックデザイン使うかというと別にそんな使わないし意識してるとも思えないですけど、
ただ概念的に、自分の思想としてこういうものをベースにしてるっていうので、アトミックデザインを一回読むだけでもその価値はあると思います。
あとはその諸々の各種CDNとかありますよね、その辺とかですね。
フロントエンドはさらにそれからいろいろ考えなきゃいけないことがまだいっぱいありましてですね、
現代ではアクセシビリティだったりとかウェブコンポーネントだったりとか、ほぼほぼ使うことないと勝手に思ってますけどPWAとか。
PWAも要素によっては使うよっていうのがありますね。
あるとしたらオフライン対応とか、あとはAdd to Home Screenとかあったりしますけど、この辺もPWAの要素の一つなので使わないかなと思ったりします。
あとはLighthouseを使ったパフォーマンスの話も出てくると思いますし、セキュリティの話もあると思いますし、SEOの話もちょっとして、SSRをまだするかもしれないですね。
Googlebotがだいぶ進化してきたっていうのはありますけど、でもそういってもまだまだ対応しきれないというか、重いサイトだとやはりサーバーサイトレンダリングしないとSEOが効かないよねっていう話が出てきたりはしますね、その辺とかですかね。
あとは今後来るかわかんないですけど、リアクトサーバーコンポーネンツっていうのが新しい概念とか考え方が出てきているので、フロントエンドって本当に変化が激しいというかいろんなものがどんどん出てくるので、それを全部追っていかなきゃいけないと。
それが結構つらいねって話もありますし、どうやってそれを追っていくかっていう話を今日はするという感じですね。
とにかくカオスですねっていう、僕も今バーッとしゃべりましたけど別に名前だけ出して説明しなくてもよかったかなと思います。
これ別にまだ前置きの話ですからね。
なんですけど我々エンジニアですので技術者として、技術のプロとしてやはりどういう技術を使うかとか、どういう技術がダメなのか、今回のプロジェクトではあえてこっちを使いましょうみたいなことを技術的視点で選択をしていかなければいけないんですね。
12:05
そこに対して僕らはプロとしての責任があるという感じです。
自分の例とか本番はしゃべったんですけど、ちょっとこれしゃべっていくのが長いんで、ざっと言うとNextを使ったりNextを使ったり、あとはLIFFっていうLine Mini Appのフレームワークを使ったり。
プロジェクト的にはTypeScriptを使ったり、リコイルを使ったり、TetJetを使ったりとかね。
プロジェクトによってテストとしてViewTestUtilsを使ったりとか、SSRするからNobleJSのExpressJSを使ったりとか、デプロイとかリソースの管理として最終的にDockerのコンテナ化していって、それを全部コンテナで管理しているっていうところをプロジェクトにもあったりするので、Dockerも必要があげないとか。
あとはですね、プロジェクトによってレフトAPIじゃなくて、Appleを使ってGraphQLを使ってデータのやり取りをするっていうプロジェクトになったりするとか、いろいろあるわけですよね。
こんなにいっぱいあるわけなので、僕みたいにいろんなプロジェクトを横断してレビューするようなメンバーもそうですけど、エンジニアの方もですね、アサインされたエンジニアもいろんな技術を使えるっていうことが前提になってくるような話だと思いますし、そういうことが求められてくると思っております。
やっぱりプロですね、僕らリードするとか、マネジメントする人も、そんな末端のちゃんとした技術の全部を知っているとは思えないし、そんな時間もやっぱりないわけなんですよね。
なので、やっぱりそこは現場にお任せしたいし、現場の人に意思決定をしてもらいたいというところもやっぱりあったりはします。
逆に言うと、現場はそういうことを知って、僕は今回のプロジェクトではこっちの技術を使う方が生産性も上がるし、保守性も上がるしみたいなところをちゃんと、逆に提案しておいても欲しいなって思っていますので、
やはりエンジニアもそういうのをどんどんキッチャップをして、自分の力として欲しいなとは思っておりますね。
というところで、いっぱいこうやってあるので、そんな技術の学び方をどうやってやるのかというこの先の話をあくまで参考例として、自分の経験値をお伝えしたいなという話でした。
というところで、もうすでに14分ぐらい喋っているんですね。長い。
後半ちょっと駆け足になるかもしれないですけど、やっていきたいと思います。
前置きをしましたけど、この話はやっぱりフロントエンドとかに関係ないというか、フロントエンドにとどまらないと思っていますので、そういう気持ちで聞いていただければなと思います。
あくまでその例を出すときに、全部フロントエンドのツールとか技術の話をするというだけであって、そんな感じですね。
じゃあ行きましょうかね。本題に入りますが、アジェンダですね。今回しゃべるアジェンダは一応4つに分かれています。
最初は、そもそもモダンフロントエンドって何ぞやという話をして、次にちょっと趣向を変えて、僕らに対して、自分たちが勉強すると思うんですけど、その学び方ですね。
自分にとってどういう学び方がベストなのかということそのものを学びましょうという話を2つ目にします。
3つ目に、じゃあ具体的に技術の追い方を勉強しましょうという話をしますという感じですね。
ラストにOSSとかコミュニティですね。というものをぜひ活用してみたらどうでしょうかという話をして、終わりになりますけどね。
15:06
で、自己紹介ですけど、このホッキャストを聞いていただいている方は、別に自己紹介を今更してもどうでもあれなので、軽く言いますと、夢見ているところでフロントエンドのサーファーとリーダーやったりとかの取締役をしてますよという感じですね。
ちなみにですね、僕はフロントエンドの話を結構してますけど、別にスペシャリストじゃなくて僕はジェネラリストな趣向ですね。
なので浅く広くなタイプなので、正直突っ込まれたりすると全然僕、話しついていけないんですよね。
なので、ぶっちゃけ言うと技術力という一点で言えば、僕よりも絶対、弊社のメンバーの方が圧倒的にレベルが高いと思います。
若干ですね、僕の今日喋る私自身の何でしょうかね、ペルソナと言いますか、いわゆる略歴をちょっと喋っていきたいなと思ってますね。
どんな人間なのかというと、一応大学院を卒業したのが2013年の3月ですね。
僕ちなみに一浪してましてですね、本当にバカ野郎だったんですけど。
で、情報系の大学の大学院まで一応行けることはできてですね。
浪人したのはうちの大学の進学ですけど。
で、別に偏差値60もいってないような、普通に2流以下の3流くらいの大学ですけどね。
まあそういうことを自分が言ったら怒られそうですけど。
大学院を卒業して、ずっと実は数学をやってたんですね。
学部生の時は複素解析のリーマン・ゼータを使ってました。
それで、大学院では結び目理論というのをやってましたね。
はい、結び目理論の何だっけ、体積予想という予想があったんですけど、それについての研究の一端をちょっと担ったという感じですね。
です。
そのまま卒業して、エスキュビズムという会社に最初入りましたね。
あの、自宅でECサイトを作るという会社ですけど。
で、こちらに2015年の10月まで在籍しまして、一応転職をして、次レプラフォン株式会社というところに移りましたね。
で、こちらでも同じような開発ですね。ECサイトとかウェブアプリケーションを作っていました。
ちなみにランプ環境ですね。
リラックス、アパッチ、マイSQL、PHPの頭4つを取ったランプっていったりしたんですけど。
そのランプ環境でECサイトを作ってたって感じですね。
で、一応エスキュビズムの時もプログラマーも最初から入ったんですけど。
いや、一応最初はテスターから入ったんですよね。
テスター入って、次に保守メンバー入って。
で、やっと1年終わりか2年目くらいになって、やっと開発させてもらえて、そこから一応プログラマーとなって。
で、3年目からプロジェクトリーダーやって、プロジェクトマネージャーもなぜかやるようになったんですね。
僕はやっぱりジェネラリストなので、喋ったりとお客さんと交渉、接触したりとか、回す方が適性があったようですね。
そこにバッティングした、その当時の部長の人とやっぱり見る目があったなと思いますね。
で、はー、ちょっと一気に喋ってるからそろそろ疲れてきましたね。
はい、では行きますよ。
で、続いて、そういうことをやってて、レプラフォン株式会社も2017年の8月まで実は在籍して、1年と10ヶ月くらいですかね。
在籍しました。で、同じようにプロジェクトリーダーやって、プロジェクトマネージャーだったりとかしましたね。
で、1案件だけ直後でフロントエンドもやったりは実はしたんですけど、まあ本当に一瞬って感じですね。
18:01
はい、やっててもう1回やっぱり転職して、今の夢見っていう会社に来ました。
夢見に入って、最初はやっぱりもう1回プログラマに戻ってですね、ノードJSでAPIをずっと作ってたって感じです。
はい、で、そこから2年目になるときにフロントエンドやりてーって言ったら、どっかのプロジェクトマネージャーの人が降りてきて、
ああ、じゃあこういう案件があるけどちょっと入ってくれないって言われて、
で、プロジェクトにアサインしていただいて、フロントエンドエンジニアとしてスタートしたんですけど、
まさかのですね、一応コードも書いたんですけど、僕スタートからフロントエンドのエンジニアのリーダーだったんですよ。
現場としてプロジェクトの開発をやったので1案件しかないのに、いきなりリーダーかよと思いながら、まあまあいいやと思いながらずっとやってきて、今に至るんですね。
で、2020年の3月ですね。3月にひめみの鳥島焼に就任させていただいて、今人気2年目がスタートしたっていう感じです。
もちろんちょうどそうですね、3月16日だったっけ?だった気がするので、明日から本当にひめみにスタートという感じですね。
そんなところで僕は結局いろんなことやったけど、基本的にはプロじゃなくて幅広くやったっていうだけなので、そういうジェネレーションだよっていう話だけ聞いていただければ。
特に一流企業に行ったような花々しい経歴があるわけでももちろんなく、本当にただの一平率っていう、一平率って感じです。
で、続いた本題にやっと戻りますけど、本題に入ったとき一発目ですね。一発目がモダン・フロントエンディンス何?って話をするんですけど、
スタンダードFMを聞いてくださっている方の中には多分もうすでに聞いたことあるよって方も多分いらっしゃると思います。
第88回だったかな?で、一応僕喋ってるんですね、モダン・フロントエンディンスの話を。
で、今回の話は本当にもろかぶりなのでぶっちゃけると喝采します。それぐらい似たような話ですね。
ざっくり外略だけ喋ると、昔はとにかくモノリシックだったって話なんですよ。
一つのサーバーの中にWebサーバーも入ったり、WebサーバーってApacheとかNginxとかとかアプリケーションその本体が入ったり。
アプリケーションもフロントとかバックとか特に切り分けとかなくてですね、イメージとしてはいわゆるララベルとかを使って、
側もやるし、コントローラーもモデルも全部一緒に実装しますよみたいなお話ですね。
とかやったりとか、データベースも下手したら一つのサーバーに入っている時もあったりしたんですよ、昔は。
ひどいですよね、冗長化を全然しなくて、このサーバーもし死んだりストップしたら、ユーザー一切そのサービスを使えませんみたいな、
すごい危険な状況なんですけど、昔はでも本当にそれ当たり前にあったんですよ。
いやー、なんかおかしい時代でしたねって思います。
あとログファイルも下手したら同じサーバーにあったりして、もうどうしようもねえなみたいなとこあったりするんです。
基本的にせめてデータベースとかログファイルとかは別に分けてねとかあったりはしますけどね。
モノリシックにやってたんですね。
さらにモノリシック、もうちょっとアプリケーション本体に見てみると、そちらもやっぱりモノリシックらしくですね、
さっきも言ったようにViewModelControllerというMVCというアーキテクトがあって、その通り作られてたんですね。
なのでサーバーサイドのフレームワークと言語なのに側も作ると。
で、そのView側のところでテンプレートエンジンとか昔は、今もあるんですけどね。
21:02
ラベルだったらなんだっけ、あー名前出てこないですね。
その名前出てこないですけど、PHPだとよくツイグとかスマーティみたいなテンプレートエンジンがあったんですよ。
Node.jsだとEJSとかあったりしますし、フロントエンジンとかだとなんだっけ、
えーっと、ほんとに出てこないな。
やばい、最近使ってないですけど、いわゆるテンプレートエンジンがたくさんあったって感じですね。
なんかJから始まった気がしますけどフロントエンジンのやつは。
はい、まあまあいいや、出てこないですね。
今、名前変わってPugになった感じですね。
Pugっていうテンプレートエンジンが一応あるんですよ。
まあ書きづらいと思いますし、確かにHTMLを書くって量が半分に減るんで、
それはそれでメリットなんですけど落とし穴もいっぱいあって、
正直書きづらいしパフォーマンスそんなに上がらないんで、
別に使わなくていいなと思っていますね。
まだ昔はそういうのがあって、HTML側の中でも一応ロジックができますというところで
エンジンを使うことも結構メリットとしてなくはなかったんですよね。
なんですけど、結局側とロジックとかコントローラーとかが密接に関わっていて、
はっきり言って全然フロントとかバックの関係ねえじゃんみたいな。
正直開発性も保守性も悪くてですね、拡張性も悪いっていう、
まさしくこの一枚刃っていうモノレーシックな設計だったわけですよ。
これはよろしくないよねっていうので、
今現代だとちゃんとサーバーサイドとフロントエンジンとデータベースとかをしっかり分けましょうねっていうところです。
クライアントはクライアント側っていうところで、
わかりやすくリアクトとかビュートとか、
スベルトとか使ってるとだいたいモダンフロントエンドに行ってもほぼ間違いはないかなと思います。
ちょっと語弊も招きながら言ってますけど。
ロジックのところとかサーバーサイドのところはしっかりAPIに切り分けてあって、
APIをAPIとして作ります。
フロントエンドはそれをコールするだけですね。
非同期で通信やり取りをしてデータを取ってきて、それに色をつける。
CSSとかで装飾をして、最後レンダリングして側として、
画面にお客さんと画面にして見せるというのがいわゆるモダンな開発なのかなと思います。
あとはもちろん自動デプロイするとかもそうですし、
お客さんは基本的にUIとかを触って操作するんですけど、
その操作した結果、画面の変化するのは全部JavaScriptでコントロールしましょうみたいなところですね。
なってるのが今のところフロントエンド側かなと思ったりはしています。
もちろんAPI側の方もデータベースAPIちゃんと切り出されていて、
ちゃんと分割したマイクロサービスじゃないですけど、
そういう形になっているのがいいのかなと思っています。
一応ざっくり言ったんですけど、フロントエンドの話にもうちょっとキーワードを出すと、
ここもちょっと火災ですね。ボンボン飛ばしていきます。
キーワードを出すと、GUIのアプリケーションを作るのがフロントエンドですね。
それは全部JavaScriptで作られているというのは前提です。
あとは先ほど言った通り、バックエンドとフロントエンドがしっかり切り分けられている開発が、
モダン開発なのかなと思っています。
フロントはフロントでサーバーサイドはサーバーサイドというところですね。
あとシングルページアプリケーションですね。
SPAを作っていたら、これもだいたいほぼモダンと言っても過言ではないんじゃないかなと思います。
逆に言うとSPAを作っていなくてモダンかって言われたら、
24:00
多分いろんなフロントエンドエンジニアが頭をかしげると思うので、そんなところですね。
あとは他のワードが出てきたら、これも一応モダンな環境なんだろうなというのをいくつか言いますと、
PWAとかSSR、サーバーサイドレンダリングとか、タイプスクリプトを使っているとか、CICDを使っているとか、
JAMスタックですね。
JavaScript APIマークアップの略ですね。
こちらもちょっとJAMって言うんですけど、JAMスタック。
これも一応フロントエンドのモダンかなと思います。
で、ちょっと喋ったんですけど、モダンフロントエンド何がいいのって話ですけど、
これは第88回で喋っているので、ざっくり2つありますというだけ言いますね、2つ。
1つ目はですね、Improving the User Experienceなので、
ユーザーエクスペリエンス、ユーザーの体験ですね、UXの向上につながるというのが1つです。
2つ目はImproved Developer Experienceなので、開発者の体験ですね、開発体験が高いDXです。
この2つが向上するというのがそのメリットですね。
2つの大きなメリットなので、モダンフロントエンドはそういうところを見せて、
体制とか開発の環境とかが努っていくという感じです。
ただ、デメリットもありまして、いろんなデメリットもあるんですけど、
集約すると初期コスト、イニシャルコストが高いというところです。
開発するのもそうですし、学習するのもそうなんです。
最初に学習するものが結構増えるんですよね、モダンのものを作りたいとなったら。
というところで、いろんなものが便利になって、
細分化したりとか、押し上がったりとかなった分、
学習するものがいっぱい増えたりとか、考えるものがいっぱい増えてくるというところで、
イニシャルコストは高いよという話があります。
あとはSPAを作っていると、
一番最初の初期レンダリングのスピードが遅くなるというところはやっぱり重いですね。
昔はちゃんと各ページごとにHTMLファイルがあったんですけど、
SPAということは結局シングルページなのでHTMLは一つなんですけど、
各ページとかコンテンツ出すものも全部まとめて最初にガスンとダウンロードしてくるんですよ。
そのダウンロードして解析しなきゃいけない、そこが重い。
なのでSPAを作るときは結構重いですよという、そこが悩みであって、
一応デメリットを解決策ももちろんあるんですよ。
ちゃんと分けするとか、
最初に全部持ってくるんじゃなくて、
必要なものだけを最初に取ってくるとか、いろいろやり方はあったりして、
エンジンの腕の見せ所などはあるんですけど、
それでもやっぱり考えることはやはり最小号機の例、
やっぱりイニチュアルコストが高いというのが、
モダンな開発環境とかのデメリットというか、悩みの種ではあります。
というところですね。
今のが一応最初のモダンフロントエンドとは何ぞやという話でした。
詳しい話は第88回があるので、ぜひ聞いていただければなと思います。
2つ目ですけど、自分にとってベストな勉強方法を勉強しようという話です。
皆さんは自分にとってベストな学び方というのがちゃんと確立されていますかというところですね。
やっぱり自分にとってマッチするとかベストな勉強方法を知らないと、
学習のスピードが上がらないというか、むしろどんどん自分の時間を食われるわけですよね。
勉強の仕方っていっぱいあると思って、
パソコンを見てデジタルに勉強する方もいれば、
27:00
トイレに持って本を読むみたいな人もいれば、
自分一人じゃできないから、やっぱりみんながいる場所で黙々やるという方がいいという人もいれば、
いわゆる観客効果ですね。
というのもあれば、ひたすら音楽を聴いて自分の世界にずっとこもりながらやるとか、
パソコンを使わずにひたすらノートに書いたりするとか、
社教するとかいう勉強方法の仕方もあったりします。
いろんなものがありますけど、
とりわけ自分に合ったもの、自分にとってベストなものを選んでみましょうと。
相性がいいものをやったほうがいいなと思いますね。
自分はデジタル苦手なのにずっとパソコンとかデジタルで勉強してたら、
やっぱり苦手なものなので、なかなか頭に入らなかったりして、
普通にやるよりも8時間以上オーバーしてしまうとか、
1時間で身につくものが8時間かかってしまうみたいなときもなくはないわけですよ。
それは時間がもったいないですね。
自分の人生の短いですし、学ぶものがどんどん増えてくるので、
それを早く、いかに早くキャッチアップしていくかというところが大事なので、
学習のパフォーマンスを上げるためにも、自分の学習の体制というか仕組みというか、
やり方というのをしっかり構築していくことが結構大事だよというお話をしました。
エビングハウスの包却曲線というものがあったりします。
物事を覚えるときに忘れることに関する研究でいっぱい世界中でされていて、
今日は2つ出すんですけど、そのうちの1つがエビングハウスという方の包却曲線のお話です。
このグラフはググってください。いっぱい出てくると思います。
いっぱい出てくるんですけど、縦軸の意味だけ気をつけてください。
縦軸の意味は何時間とか何分とか経ったら、どれだけ頭の中に記憶が残っているかということではなくて、
逆に言うとどれだけ忘れてしまったパーセントなのかという勘違いをされるかと思いますが、それも違うんですね。
これは縦軸は節約率ですね。
復習するときにどれだけエネルギーを節約できるかというところのパーセンテージです。
20分たすと50%が失われるので、50%ぐらい節約できなくなっているので、それぐらいエネルギーを使いますよという話ですね。
1日も出すとだいたい33%失ってしまうので、残り67%のエネルギーをやっぱり使わなきゃいけないので、
ほぼほぼ半分以上もう1回勉強するぐらいの勢いになってくるねという話です。
もう1回以上出すと25%になってくるので、残り75%ということで、ここから先はあんまり減らないらしいですね。
節約はあんまりできないけれど、ちょっとは残っているよという感じらしいです。
という研究もあればですね、もう1個なんだっけ、カナダの大学、ウォータールー大学が研究していた防脚曲線というのがあって、それも結構似てるんですけど、
1日目は結構100%覚えていて、結構失われないんですけど、2日目ですね。2日目は復習しないとだいたい60%が、下手したら80%ぐらい失われていくというところですね。
1週間から確か30日とか行くとほぼほぼゼロというふうに研究結果が出ていて、1週間でもだいたい90%ぐらい忘れていて、ほぼ忘れているねというところにつながるので、しっかり復習はしたほうがいいよねという研究なんですけど。
30:00
1日目はいいとしていて、2日目ですね。2日目にどれだけ復習したらいいのかという話なんですけど、実は10分間だけ復習するだけでほぼ100%に戻ってくるということで、しっかり思い出せるという話をしているんですよ。
これは2日目というのが結構キーポイントらしいですね。2日目1回やった人は、次ですね、1週間後ですね。1週間後でもたった5分でいいらしいですね。復習するだけでちゃんと元に戻ってくると。
ほぼ100%は思い出したわという感じになるので、これぐらいということでしっかり復習したほうがいいよということですね。1ヶ月後ですね、次。ふっとぶんですけど、1ヶ月後は2分から4分でいいらしいです。
というところで、これは3回復習している人はほぼほぼ定着しているということなんですよね。
復習はやっぱり1回じゃなくて2回やるのほうが確実だねというのが結構いろんなところで言われているので、それもしたほうがいいんじゃないかなと思いますけど、
いわゆるさっきの学習のスタイルと同様で、自分の中でリズムのいい勉強法とリリースのスタイルをしっかり作っていくというのが大事ですね。
それと復習のリズムを考えていくのがいいと思います。というところですね。この辺を気をつけて、自分のベストなやり方を作っていただければと思います。
でまぁだいたい30分なので、ちょっと一呼吸を使ってください。結構マシンガンのように喋っていて。
本番当時はこんなマシンガンのように喋っていないんですけど、今は一人で喋っているだけなので、バババッと喋りたいが、マシンガンになってしまいました。
結果、かつあいというか、結構ざっくり喋ろうと思ったんですけど、わりと本番と同じくらいの難易度、濃さで喋ってしまっているので、
ちょっと早口で、なおかつ情報量も多くて聞きづらいかもしれないですけど、すみません。
そういうところで続きいきましょうかね。続きあと2つですけど。
次のトピックは、具体的にどういう勉強の仕方がありますか?という技術の追い方、何がありますか?というのをお話ししますけど、いっぱいあるんですけど、学び方なんでね。
動画で勉強する方もあれば、古代の勉強の仕方で、ソースコードを見て、本で勉強する、ひたすらガリガリ社教をするというのももちろんありますし、
あとはですね、概要だけ知って、実際にアプリケーションを作ってみましょうという方もいらっしゃいます。
いろんな勉強の仕方があると思いますね。
なんですけど、まあまあまあ、自分の中で好きなものを選んでもいただければ良いのかなともちろん思いますけど、
勉強するときにですね、結構聞かれる質問として、たくさんのものがいっぱいあるじゃないですか、フレームワークとかライブラリとか言語もそうですけど、
そういうのを同時に勉強したらいいのか?という質問をたまに受けたりします。
僕の答えとしてはNOで、1個これを勉強しましょうというのを突き詰めていった方がむしろ良いと思います。
例えばフレームワークの話ですね。
フレームワークだったら何か勉強したい点がフロントエンドで言うと、
僕の結構お勧めするのはNext.jsもしくはNext.jsですけど、
今は僕はNext.ゴリ押しですね。
リアクトラップした拡張したフレームワークですけど。
なんでもいいけど、1個選んでそれを深く勉強したら良いと思います。
33:03
そうするとですね、他のフレームワーク行っても結構通じるというか、意味が分かるんですよ。
なんでしょうね。
だいたい機能というか必要になるものってほぼ似てくるんですよ。
フレームワークというか、言語もそうですけど。
例えばですけど、データのバインディングする機能とかですかね。
バインディングというのは、HTMLの方とロジックからデータをやり取りしたものを反映していくというところですけど、
そこのバインディング機能もそうだし、
ページ遷移するときってやっぱりSPAっぽく作るんだったらルーティングっていう機能があるんですけど。
ルーティング機能もあったりとか、レンダリングする途中とか、レンダリング後に何か起こすとか、
更新するとき、更新前、更新後に何かするとか、
みたいなところでライフサイクル機能とかやっぱりあるんですね。
そういう関数が定義されていますかとかですね。
あとはビルドするときのコンフィグとか、設定周りがちゃんとできますかみたいな機能とか。
あとはですね、現代だとLiveSPを作るので、その状態管理をしなきゃいけないって話をしましたね。
その状態の、いわゆる状態管理をするステートマネジメントの機能だったりとか、
いうものがあったりします。
他にもいっぱいあったりするんですけど、大体こういうのって、
今のモダンなフロントエンドのフレームワークだと、ほぼほぼ持っているんですよ。
なのでこっちの機能では、フレームワークだとかライブラリーではこういう書き方をしたけど、
こっちはこうやって書くので、ふーんって感じになるので、
一個学ぶとほぼ他のものを学ぶとあんまり変わらないんですよね。
ただ、ユーザーインターフェース、UIとか書き方、APIとかが違うだけなので。
なので何か一つ選んで、しっかり勉強したらいいんじゃないかなと思います。
あと、たくさん学ぶものがいっぱいあるじゃないですか。
エンジニアになって、物事が結構分かってきたり、
いろんなものを勉強して身についてくると見えてくるものがたくさんあって、
そうするとあれもこれもこれもみたいな感じで、
勉強したくなってくるものがもっと増えてくるんですよ。
そういう気持ちが分かって、僕もいっぱいあるんですけど。
そういうものを一回で、学びたいものをリスト化してください、皆さん。
自分の中でバーンと、何でもいいです。
別にインフラでもいいですし、何でもいいですし、
カテゴリーとかわけなくても、ぶっちゃけ僕はいいと思ってます。
片っ端からどんどんリスト化していって、それを自分の中で優先度をつけて、
高いものからもう上からどんどん手をつけていくっていう風につけると思います。
ただその勉強方の仕方的にアプリケーションを作るっていうやり方をする方は、
その複数の言語とかツールとかライブラリとかを同時に勉強するっていう風になるとは思います。
例えばECサイトを作るとしても、言語をとりあえずPHPで選ぶなら言語PHPですねって、
フレームワークパラグですねって。
データベースは一回とりあえずマイナスケールでやりましょうとか。
環境的には一回Docker使ってコンテナ化したいですねって言って、
じゃあDockerを勉強しましょうとか。
で、ウェブサーバーはやっぱり流行りのNginxをとりあえず使ってみましょうとかって感じで。
もうすでにいっぱい今のわけで5、6個出てくるじゃないですか。
こういうのを同時に勉強するっていうやり方ももちろんあったりします。
なのでそうなった場合はリストの中から5、6個をどんどんチェックをつけていって勉強していくっていう。
別にそれもいいと思います。
とにかく自分でリストを作って優先度をつけて、
それをどんどん片っ端から手を動かしていくことに尽きると思います。
これはやっぱり一番早いと思いますね。
36:00
動かした量で、量もそうですし、考えながら手を動かした量が自分の速攻になってくるので、
速攻の量に尽きるのでガリガリ手を動かしていったらいいんじゃないかなとも言います。
あとはですね、よく聞かれるものとして、
なんだっけ、どういう媒体を使って勉強したらいいの?って聞かれますけど、
日本人の方はよくやりがちなんですけど、
僕はやりがちであんまりよろしくないやり方もあるんですけど、
私のおすすめはやっぱり一時情報に触れるですね。
ツールだったり言語だったりでもいいですけど、
公式サイトに行くと大体ライブラリとかツールってチュートリアルが結構用意されたりするんですね。
それを見ていくのがいいと思います。
なんだかんだ公式ドキュメントが一番しっかりしてるとは思うんで。
というところですね。
特にもしよろしければというか、
エネルギーがあるのであればできれば原文ですね。
英語で書いてあるのは大体英語だと思います。
なのでその英語を読んでいただくのが僕は良いかなと思っております。
その次にですね、一回読んだりチュートリアル手を動かして、
よしよし、なんか分かってきそうになったらそのアプリケーション作るとか。
僕は結構最近は動画サービスですね。
動画学習サービスを使うことをお勧めしてますね。
僕は結構UDemyを使ってますけども。
実際に講演者の方、プロの方が自分で手を動かしてるのもその場で見せてくれたりするので、
それを見ながらやるっていうのは結構いろいろ学びがあって大きいですし、
その人たちもやっぱりなんかアプリケーション作るんですよ、動画中に。
それをそのまま見ながら作ったりして、
自分でも考えながらああでもないコード名とか加工してみたりすると結構いいのかなと思います。
もう一個だけアドバイスすると、
できれば二次情報から入るのだけはできるだけ避けてください。
これ結構大事で。
二次情報って要は本来勉強するべき本質のものの概略とかざっくりとしたものをバッと出すんですね。
それってやっぱり需要はありますし、
飲み込みが早いんですよ。
飲み込みっていうのはそのツールがどういうものかっていう概要種類に関しては本当に一番早いんですよね。
本家よりも早いです。
なんですけど、それでわかった気になって止まってしまう人もいたりとか、
本質のところとか、
落とし穴のところまで行かないまま、
これでわかったよっていう風になって学習やめてしまうことって結構多くて、
それはちょっと危険なんです。
やっぱり技術者としてそこを理解しないっていうことは結局、
あるプロジェクトでこのアプリケーションを作ったときに、
このツール使えるじゃんって新しく知ったやつをやっぱりチャレンジしてみたいって入れるんですけど、
落とし穴とか知らなかったり本質を理解しないと、
本質的なものがこの作りたいプロジェクトのアプリケーションとマッチしないときとかは本当泥沼に入るんで、
結果としてより高数かかったりとか納期とかリスクもあったりするので、
僕はそこをお勧めしたいんで、やっぱり二次情報に触れるのは、
あくまで落とし穴とかにぶち当たったときに二次情報を調べていって、
ああなるほどここで聞いたとか前にそういう記事あるじゃんって、
あとはタップオーバーフローで同じような落とし穴にハマった人いるねっていうので調べて、
39:02
その記事を参考にするのはいいと思います。
けど最初の学習としていきなり聞いたとか前から入るのは僕はあんまりお勧めしないなというところなので、
あまりコードを書かない人とかプロジェクトマネージメントをする人とかが、
情報収集のために知っておくのがいいと思います。
知ったけどそれが本当はどういうこととかメリディベなんなのっていうのは、
ちゃんと知ってる人に聞くのが大事だと思います。
そういうことをしないのであれば、
絶対に二次情報はむしろ触れることすらしない方がいいと僕は思っていますね、というところです。
今のがその三つ目ですね、具体的な勉強の仕方というところでした。
ラストはOSFとかコミュニティを使いましょうという話ですね。
使いましょうとか利用したらいいよっていうお勧めのお話をして終わりにしたいと思いますけど、
今更OSFが何ぞやって話は別に知ってなくても分かると思いますけど、
一応オープンソースソフトウェアの略ですね、詳しい話はググってください。
要はいろんなところで見れておりますけど、
GitHubとかGitLabとか何でもありますけど、
ソースコードそのものが公開されているようなソフトウェアのことです。
すごいざっくりで言ってますけど。
オープンソースソフトウェアですね、OSFって今どんだけあるのとか、
どれぐらいの量があるのかあると思いますけど、
これがですね、日本OSF推進フォーラムっていうのがありまして、
そういうサイトがあるんでググっていただければすぐ出てくるんですけど、
それのOSF館図というのがあります。
これの2020年版が昨年6月30日に出て、今年の部分また出ると思うんですけど、
このサイトに行くと載ってるんで、
だいたい僕らが思っている、名前浮かぶようなOSFって結構本にも載っかったりしているので、
いろんなものが本当にOSFになっているところですね。
すげー時代になりましたねと思います。
私は全然、公開することなんて思っているのかみたいな時代があったので、
今はいい時代になったなと思いますけど、
ほんの参考程度に見ていただければと思います。
日本OSS推進フォーラムですね。
OSSを使うことは、プロジェクトとか実際にお仕事で使うことはあると思うんですけど、
OSSを使うときに注意してほしいのは、
OSSってライセンスがあるんですね。
どういう目的とかどういう使い方をするのかっていうところに気をつけないといけない。
そういうことが明記されたライセンスというのが基本的にライブラリーには付与されているので、
それをお間違えないように。
ライセンスの勉強も結構したほうがいいんですけど、
これもやりだすともう1時間ぐらい喋れるので、
課題はします。
すいませんけど、ググっていただけると思います。
困ったらとりあえずMITってやつですね。
摂取設置効果大学が作ったライセンスなんですけど、
このライセンスが使われていれば基本的には大丈夫なので、
MITリポジトリを見たらOKって感じで使っても大丈夫だと思います。
GitHubのリポジトリを見たら右のカラムにMITって出てきたりするので、
そういうところですね。
OSSの話は結構喋ってますけど、
なんでそんなにお前はそれをお勧めするんだっていう話ですね。
なんでOSSを進めるかというと3つぐらい理由があってですね。
42:01
1つは世界中のエンジニアからフィードバックをもらえることができるというところが本当に大きいなと思います。
これはやっぱりエンジニアなのでわかると思いますけど、
誰かからフィードバックをもらったりとかレビューをもらったりするのって本当に学びになるし、
自分の成長につながるので、
それが世界中のエンジニアからもらえるって本当にデカいんですよ。
なのでこれはぜひやったほうがいいと思います。
2つ目はそういう世界中のエンジニアのソースコードの設計とか考え方が思想とかをこちらが勉強することができるというところですね。
どういう書き方してるのとかここはなんでそういう設計になってるのっていうのも正直聞いたら教えてくれるだろうし、
そういう人たちのソースコードを読めるっていうのはなかなか勉強につながるのでぜひぜひこれをOSSでやっていただければいいと思いますし、
読書と銘打って全然オープンソースになっているライブラリーのソースコードを読むっていうのもいいと思います。
本当に結構難しいところもいっぱいあるし、
やっぱり有名どころのライブラリーとか大きいライブラリーとかになるとソースコードが難しいので、
最初は軽微なものとか簡単なもの、ちっちゃいものから読んでいくのがいいのかなと思います。
困ったらあれですね、
僕のおすすめはなんだっけ、
ローダッシュっていうJavaScriptのユーティルがまとまったユーティル関数の塊みたいなライブラリーがあるんですけど、
ローダッシュって言います、それですね。
昔はアンダースコアって言われてましたけど、
っていうものがあるので、
それのソースコードはめちゃめちゃ読みやすいし、
一個一個のユーティル自体は結構少ない、
コード量は短いので、
かなり勉強しやすいと思うので、
ぜひ読んでいただければなと思います。
あとはですね、
OSSをお勧めするもう一個の理由は、
3つ目はセルフブランディングですね。
これもいろんな方が常におっしゃってますし、
僕も結構いろんなところで言ってるんですけど、
やっぱり自分の市場価値とか、
エンジニアとしての市場価値を上げることで、
やっぱり目的としてやっぱりあると思っていて、
むしろ上げた方が絶対にいいと思ってるんですよ。
それでOSSはそれがまさに直結することなので、
セルフブランディングつながるので、
ぜひやっていただければなと思います。
私のはやっぱりライオウトジエスですね。
ライオウトジエスっていうUIライブラリーがあるんですけど、
僕はそれの一応コラボレーターですね。
コアメンバーの中の一人としています。
日本人では2人目ですね。
私含めて合計3人いるんですけど、
そのうちの2人目が私ですね。
あとはそうですね、
自分でNPMにノードジエスでライブラリーを作って、
公開したりします。
全世界からダウンロードされてますけどね。
僕はJavaScript好きなのでNPMを選んでますけどね。
今のところダウンロード数も一番多いやつだと、
もうそろそろ1万件ダウンロードしそうなものもあれば、
最近出したばっかりで、
まだダウンロード300件しかないと思ったりしますけど、
こんな数が出てきたりするので、
こういうのを見るのも嬉しいですし、
こういう実績とかを持って、
他の会社の転職とか採用に持っていくと、
結構刺さるんですよね。
この人いろんなことやってるじゃんということで、
いろんな勉強もしてるし、
アウトプットもしてるってところで、
本当にちゃんと学んでるってことが目に見えるので、
これ結構評価もらえるので、
45:00
ぜひオススメですね。
自分でライブラリーを作って公開するっても結構大事かなと思います。
で、次ですね。
OSSをどうやって始めればいいの?
っていう質問をたまに受けますけど、
こちらですね、結構いっぱいあるんですけど、
僕5つオススメのやり方があって、
簡単な方から難しい方にいきます。
一番最初に簡単な方からいくと、
何かリポジトリ選んで、
それのドキュメントを更新するっていうプロジェクトを出すだけが、
一番簡単かと思ってます。
そもそもそういうプロジェクトを出せるかどうかっていう、
ドキュメントがちゃんとまとまってたり、
一点の狂いもなければ出すことはできないですけど、
でも、もし5字脱字1個で終わったら別にそれだけでもいいと思います。
それにプロジェクト修正出したよっていうデータをあげてあげるで、
それがもし回収されたら、
その瞬間あなたはそのOSSに貢献したっていうことに繋がるので、
これが一番簡単かなと思います。
次はいろんな公式ライブラリーがあるんですけど、
それの公式サイトの日本語訳ですね。
日本語訳したライブラリーとかサイトも結構いっぱいあるんですけど、
でもまだ全部じゃなかったりとか、
翻訳があまりにも機械翻訳すぎて固いとかするので、
それの更新したりとかも全然OSSとして成り立つというか、
ちゃんと認められた活動なので、
困ったら翻訳をするっていうのも結構全然ありだと思います。
いろんなライブラリーまだまだ翻訳できないのでたくさんありますので、
お勧めしたいと思います。
で、3つ目が先ほど言った通り、
自分のライブラリーとかを作って公開してしまおうっていうところですね。
これもOSSです。
4つ目はそんなビューであったり略もそうですけど、
サンプルリポジトリって結構あったりするんですよ。
こういう使い方をしますよとか、
こういう開発任務を使ってくださりとか、
サンプル的にこんな風なものを作ったりできますよって、
リポジトリって結構あったりするんです。
それのメンテナンスをするとか、
自分でこういう使い方もあるよっていうのを自分でコミットして、
これも追加してくれる事例に、みたいなところでプルリクを出すとか、
もう全然ありだと思います。
ラストはやっぱり本体の方の機能開発とか、
バグ修正とかのプルリクエストを出すというのがOSSです。
ラストのこれは本当にレベル高いので、
ちょっとハードルも高いですし、
やれる人は全然ガンガンやってくると思うんですけど、
一番最初の人は速攻じゃなくて、
最初はもうオンエアから入るのが一番楽であるかなと思いますね。
次ですね。
コミュニティに所属した方がいいよっていう理由ですけど、
コミュニティの話ですね。
コミュニティの方は僕が何でお勧めするかというと、
やっぱりいろんな経歴とかいろんなキャリアを持っている人がたくさんいるのがコミュニティなので、
そのところからいろんな情報が仕入れられるのが結構大きいですね。
最新情報もそうですし、
自分が専門にしないところの技術の分野とかの情報とかも、
そういうコミュニティのスラックにいたりすると、
そういう人たちが勝手に喋ってくれたりするみたいなのがあったりするので、
僕が何を知らないかっていうことを教えてくれるっていうのも結構コミュニティにあって、
48:00
それはかなり大きいんですよ。
知らないことを知れるっていう経験値はかなりでかくて、
そういう口を持っていることっていうのは本当にこの先の武器にもなるので、
ぜひこれを得るためにもコミュニティに所属するのは結構ありかなと思っております。
あと次はですね、次のメリットとしては、
えーと、なんだっけ、あれですね、
困った時に助けてくれる可能性が高いというところです。
僕も結構仕事中に困ったりして、
ググったけどなんか出てこない、
もしくはこれじゃないんだよなみたいな、
惜しいけど違うみたいな結構あったりする。
そういう時に、そういうコミュニティとかのスラップに、
こういう質問があるとか、こういうところ悩んだよねって軽く投げてみると、
経験値からアドバイスくれたりとか、
こうやったら解決するかもねっていうアイディアをくれたりするっていうのもあったりして、
結構助けられてるんですよね。
なのでコミュニティに所属するのは結構大事かなと思いますし、
やっぱり人の和って本当に大事だなと思いました。
で、3つ目ですね。
コミュニティのメリットの3つ目は、
予期しない、思わぬところからのチャンスが転がり込んでくるというか、
そういうことがあるんだよってお話でした。
僕の話になると、私はですね、
そのコミュニティとかに移ってからですね、
まさかの自分が書籍を出すことになったんですよね。
去年の6月に商業紙を出版しているんですけど、
先ほどの通りライオンとジェイスのライブラリーの書籍を自分で書いたんですけどね。
ちょっとゴジ出すには多すぎて、
自分でも引いてるし、
なんかあんまオススメしたくないっていう書籍なんですけど、
結構ワナビアになると思うのでオススメします。
どっちやねん。
という感じで、意外と自分が本当に予想もしてなかったような動きが、
やっぱりコミュニティとか人の関係から降りてくることがあるんですよね。
書籍を出さないとしても、
何でしょうね、
こういう勉強会に実際に自分の経験書をしゃべってくださいっていう登壇の依頼が来たりとか、
あとはこういうスタッフをやったりするとか、
こういうイベントやるんでちょっと手伝ってくれないっていうスタッフ業をやったりとか、
そこからできたコミュニティと横のつながりもやっぱり結構大きくて、
飲み会に一緒に行きましょうって言ったら全然違う企業の人とかが飲んだりすることができたりするので、
結構チャンスがどんどん広がってくるんですよね。
コミュニティに行ってと本当に予想外なコンボで結構大きさにするので、
僕もオススメしたいなと思います。
で、まあ色々しゃべりましたけど、
ラスト一応まとめですね。
もう何ですか、もう50分、50分しゃべってますね。
いや、本番よりもしゃべってるな結局。
一応まとめをしますと、タイトルと同じですね。
まとめは、そもそも今回のモダンフロントウェアって何ですかっていうところと、
自分のベストな勉強法を確立しましょうって話と、
それでは具体的にどうやってテクノロジーを勉強したらいいんですかっていう話と、
最後にOSSとコミュニティを活用しましょうっていう話でした。
というところで、結構本当にいろんなことをしゃべったし、
なんか自分の芸現象、何だかんだフワッとしかしゃべってないのがあれですけど、
技術を楽しんでもらえるやつが一番強いなっていう話をしたいと思いました。
勉強勉強って言って頑張るよりも、
このツール何だとか、これ何でしょうって、
おもちゃの感覚で遊ぶやつが一番強いのかなと思ってて、
ぜひぜひ技術を楽しんでもらうやつが本当に強いので、
51:01
それが一番いいのかなと思っております。
子供の頃みんなゲームしたりおもちゃで遊んだと思いますけど、
どんどんどんどん成長してくるじゃないですか。
上手くなっていくと思うんですけど、それと同じ感覚なんで、
技術を使って遊んでいったら気づいたら身についたっていう風な流れが一番いいのかなと思います。
はい、まあマシンガンの結局を喋って、
結局本番とほとんど同じような話をしてしまった気がして、
全然概要じゃねえじゃんっていう話がありますけど、
まあ一旦こんな感じで今回の話は以上にしたいかなと思います。
ちょっとちゃんと改良した喋り方をしてないですし、
なんかただただしくなったり、
結構噛み噛みだったり詰まってしまってばっかりで、
相変わらず喋り方が下手くそだなと思いますけど、
まあ嬉しい中でも聞いていただけるとすごく嬉しいと思いますし、
なんか聞いてみたいこととかありましたらいつでも投げていただければなと思います。
一応ですね、これからもエンジニア的な発信を今後は増やしていきたいと思っていますし、
ノートだったりかこのスタンドFNのそうですけど、
どんどん喋っていこうと思っていますので、
こんな話もしてくださいとか、
もっと深いフロントへの話をしてくださいとか言われたら全然質問しますので、
はい、お気軽に要望を投げていただければなと思います。
ではですね、今回の主力はちょっと早口で申し訳なかったですけど、
これで以上としたいかなと思います。
後日、技育祭のYouTube配信が多分出てくると思うので、
僕の配信一応聞いていただいてもいいですけど、
多分今の話を言うとほとんど変わらないですけど、
やっぱスライドがあるなしで結構多分変わってくると思うので、
このポピアストじゃなくて実際に目で見ながら勉強したいという方は、
もし興味があれば聞いていただければすごく嬉しいなと思います。
では今回の主力は以上で終わりにしたいと思います。
バイバイ。
