00:04
はい、9月28日、水曜日ですね。
地獄朝9時を回りました。
えー、すみません。
今日もですね、本当に寝起きで、
8時50何分まで寝てまして、
珍しく7時に起きなかったんだよ。
あれ、どうしたんだろうと思ってたんですけどね。
はい、ちょっとバタバタ中にして、
声もちょっと枯れてますけど、申し訳ないです。
はい、おはようございます。ひめめのkeethこと久保原です。
では、本日も朝活を始めていきたいかなと思います。
はい、えー、今日は、
昨日言った通りですけど、
昨日読んだ記事ですね。
The Web is a Harsh Managerという記事ですね。
このフロントエンドエンジニアの、
あのー、業界というか、
やること、責務というのが今かなり多い、
複雑かもしていて大変ですよね、
というところですね。
それに対してのマネジメントというところに、
対する疑問の記事を読んだんですよね。
いろいろ考えることも多いよね、
というところですけど。
はい、そこで、
貼られた記事が、
その中のリンクもたくさんあったんですけど、
その中の一つに今回の記事のタイトルですね。
The Front End Operations Engineer
というのが貼ってあったので、
ちょっと面白そうだなというところで、
今日はこれを読んでいこうかなと思っています。
はい、フロントエンドオプスみたいなところが、
キーワードだった気がするんですけど、
そこの辺からですね、
入っていきたいなと思っています。
はい、では行きましょう。
クイックサマリーですね、まずは。
チームで複雑なアプリケーションを構築する場合、
役割分担が共通していることがやっぱり多いですと。
具体的には、バックエンドでは
データベースエンジニア、アプリケーションエンジニア、
オペレーションエンジニア、あるいはこれに近いものがあります。
近年はアプリケーションのロジックを
クライアント側のフロントエンドオペレーションに
委ねるケースというのがやっぱり増えてきてますよ
というところでした。
そのケースが増えてきてますよという記事の
別のリンクが貼られてますね。
ただちょっと2013年6月11日という古い記事ですね。
フロントエンドオープスというタイトルですけど。
ここはちょっと割愛しようかなと思いますね。
またちょっと興味あるというか、
軽く僕の方で見てみますけど、
読んでみて面白そうだったらちょっと読もうかなと思います。
では実際本文に入りましょう。
チームで複雑なアプリケーションを構築する場合、
役割分担が共通していることが多いと。
具体的にはバックエンド。
バックエンドにデータベースエンジニア、
アプリケーションエンジニア、
運用エンジニアあるいはこれに近いものがあって。
同じ言葉が続けられてますね。
私は最近JavaScriptアプリケーションデプロイという記事を書きました。
これまた別の記事のリンクが貼られています。
最近というけどこれだいぶ古い。
あれか、この記事自体がもう十分古いんですね。
なるほどです。
くきさんおはようございます。
ご参加いただきありがとうございます。
この記事は本当にダラダラ読んでいるだけの感じです。
おおむね好評で内容にも満足しているのですが、
一つだけ否定的なコメントが目につきました。
おそらくそのコメントの主が
意図したような反応ではなかったでしょうけど、
03:00
それでも何かを指摘されたかったようですね。
そのコメントを見てみますと、
失礼ながら本当に仕事を楽しんでいらっしゃるのか
お伺いしてもよろしいでしょうか。
私は開発者ですけど、
技術を使って何かをするのはそれなりに楽しいです。
もしあなたの役割がアプリから最後の1秒まで
パフォーマンスを引き出すことであるなら、
そうです、これらの全てはクールでなければなりません。
でももしあなたが他のことをやっているコーダーで
この全てに戻ってくるのであれば
もう気が狂ってしまうでしょうと。
普段の仕事に加えて
こんなことを全部やらないとしたら
胃が痛くなりますよということを
ご指摘をされたそうですね。
私はこの記事を書くにあたって
少し思い込みが強すぎたようです。
私の解決案のいくつかは
世界的に通用するものではなく
多くの人がそれを実行する時間やエネルギーを
持っていないことは前もって理解をしていました。
しかしこの記事で述べた役割と
人々が頭の中で描いているフロントエンドデベロッパーの
イメージとがいかに異なるものであるか
ということを私は十分に理解していませんでした。
これまでフロントエンドデベロッパーというのは
いくつかのオペレーション業務が
その役割に含まれていただけで
それでも多くの人がそのステップをスキップする
ということを選んでいました。
いわゆるスティーブ・ソーダーズが
常にページを速くするようにどなっていた
というのはそのためですよと言っています。
そんな背景を踏まえまして
実際に本記事の本文ですね
ザ・フロントエンドオープスというタイトルの
セクションに入っていくという感じです。
私は物事をシフトしようとしていると思いますし
私は謙虚にそのシフトを導く手助けをしたいと思っています。
というところで
フロントエンドオペレーションというところです。
フロントエンドオペレーションエンジニアという
肩書というのはあまり見かけないかもしれませんが
将来的には見かけるようになることを期待しています。
実際にそんな気がしていますね。
現代で
オペレーション周りのところに注目をしてきた
というのが結構あると思います。
フロントエンドとしてもやっぱり
この辺周りというのは
わりと注目が最近はされてきたという感じがしますね。
プレイドさんの
エンジニアとして水地さんという方がいらっしゃって
水地さんは結構有名な方だと思いますけど
彼がやっぱりフロントエンドの
オプス周りのところとかを
注目したりとか
そういうブログを書いたり
勉強会でもお話をされていて
本当にフロントエンドオペレーション
フロントエンドオプスというところは
今後さらに需要が増してくるんだろうなと思っていました。
特にやっぱりCDNエッジのところですね。
彼はかなり注目をしていて
クラウドフレアD1ですね。
というところに
かなりインパクトがあると
おっしゃっていました。
僕も昨日も言った通りですけど
D1にかなり注目をしていて
でもフロントエンドの人だったら
ここのD1周りの知識とか技術を
知っておくと先に
強みを生かせるというか
自分の中の新しい強みを生み出せるという感じがするので
フロントエンドオプスというのは
今やっと終了になってくるんじゃないかな
という風な
僕は勝手に見た手があります。
どうなるかわからないですけど
例えばリアクトガーとかビューガーみたいな
06:00
フレームワーク周りでアプリケーションを
どういう風に作っていくとか設計するかというのは
もちろん重要ですし
初めてアプリケーションが作られるんですけど
それをどう運用したり
どうデプロイしたりとか
デプロイ周りをいかに高速にするかみたいな
オプス周りのところがやっぱり今後重要に増してくるんだろうな
という風に思ったりします。
またフロントエンドばっかりやっている方って
意外とその辺の知識が弱かったり
何らかのサーバー周りとか
ネットワーク周りとか
インフラ周りの知識も若干必要になってくるので
苦手な方も結構多いと思っているので
フロントエンドの中でそれができるというのは
強みになるんじゃないかなと思ったりしていました。
フロントエンドのリソースを提供し
ホスティングする専門家であるということが
やっぱり必要ですよとオプスには。
これ記事古いんですけど
グラントまたは似たようなもののプロであり
モジュールについて強い意見を持っている必要というのがあります。
グラントなんですね。
2013年ってグラントだったんですね。
そこからGulpが出て
結局Webpackに一回世界は
わーっと集約されて
現代ではBeatになるという流れですね。
バンドルツールはまた別でちょっと語りたいですね。
Webアプリケーションのパーツを
組み合わせる最適な方法を見つけ
バージョン管理、キャッシュ
デプロイのプロであるということが
DevOpsには求められるでしょう。
まさにそこですね。キャッシュとデプロイ周りですね。
フロントエンドオペレーションエンジニアというのは
外部のパフォーマンスを管理します。
新しいHTTPリクエストに対して
批判的でクリティカルで
ファイルサイズやページの
ロード時間というのを常に測定しておきます。
1秒間に何回ループさせるかというのは
アプリケーションエンジニアの仕事です。
アプリケーションエンジニアは
機能以外のすべてを所有します。
アプリケーションの意図と現実をつなぐ
かけはち層があります。
今のところそうです。
フロントエンドオペレーションエンジニアというのは
品質保証チームと非常に
親密であるパフォーマンスが
緑色に表示されるテストであることを
確認することができます。
QAと連携することは確かに多そうですね。
クライアントサイドのエラーを監視し
問題が起きたらアラートを出す。
新しいバージョンへの移行がスムーズに
行われるようにし
外部と内部の移動関係を
最新に保ち
安全で安定した状態と維持します。
彼らはアプリケーションの門馬になる
というわけですね。
今のが
フロントエンドオペレーションエンジニアの
概要のところでした。
ここから
なぜというところに入っていきたいと思います。
私たちはアプリケーションエンジニアが
仕事をする必要がないほど
運用領域で行うべき仕事が十分にある
という段階に到達しました。
一方で運用領域の
仕事もたくさんあるというところは重要で
そこをしっかり分割していくというのが
現代なんじゃないかなと思ったりしますね。
一方で
昨日読んだ記事もそうですけど
フルスタックの流れって
もう一回揺り戻しが起きてるんだろうな
とちょっと思ってますね。
レッドウッドJSとか
ブリッツみたいなのが世界でも生まれていたり
ちょっとずつちょっとずつ流行ってきてるんですよね。
ですので
フロントエンドだけじゃなくて
いわゆるバックエンドもフロントも
09:00
JSでやるわけですよね。
ノードJSができたおかげで
全部JSで一元管理してしまえばよくないと
そうするとタイプスクリプトの型定義も
バックもフロントも一元管理できるようになりますし
データベースも
ノードJSでアクセスできたりするので
それがいいよねっていうような思想だと思っていて
それは確かにあるわけですよね。
バックエンドは基本エクスプレスでやるので
基本的に全部非同期処理になると思いますけど
その辺はフロントエンドの人だったら
慣れ親しんでるなっていうのもあると思うんで
その中にやっぱり
OPSの話は絶対入ってくると思うんで
でもOPSっていうのは
フレームワークがどう変わろうが
特に変わりはないと思いますので
あとは最後
静的にビルドするか動的にデプロイするかっていうのは別の話なので
その辺周りの話は
ずっと行き続けるので
ここに専門的に
ポジションを持って
ミッションを達成する人がいるっていうのは
話としてはあるんだろうなって思いましたね。
今まではバックエンドの人とか
もしくはアーキテクトの人とか
そういうクラウド専門家の人が
やってたんでしょうけど
フロントエンドの人で
いわゆるクラウドのCDNHの方を
専門にやるっていうのは結構ありだなと思ってます。
すみません。毎回余談で申し訳ないですけど
戻ります。
アプリケーションの機能が
誰かの優先事項で
その人のプレートがいっぱいになると
ユーザーにアプリケーションを
最もうまく提供するための重要なステップの
優先順位が下がることになります。
全ての企業やチームが
このような担当者を
雇えるわけではありませんが
例え誰かが週に1日でも
フロントエンドオペレーションの帽子をかぶって
それに従って仕事の優先順位をつけるだけでも
ユーザーは得をするのです。
いくら機能が充実していても
ユーザーに素早く
簡単にそして厳しく監視されなければ
意味はありませんと。
フロントエンドオペレーションエンジニアというのは
長期的な進歩を可能にする存在なのですよ
というところでした。
ここもすごく
共感がありますね。
僕らはアプリが作りたいんですけど
本質的にアプリが作りたいのではなくて
ユーザーに
価値を提供するために
技術でそこにアプローチをしていくというところが
本質になるので
今の言葉ってすごく
良い言葉だと思いました。
では続いていきましょう。
ビルドとデプロイですね。
ここはちょっと具体的な話になるのかなと思いましたね。
実際にビルドとデプロイというところの話です。
ビルドとデプロイメント。
バックエンドエンジニアの多くに
ビルドやデプロイを従来から担当しているのだれか
と尋ねたらきっと
様々な答えが返ってくるでしょう。
しかし多くのエンジニアは
ビルドエンジニアやオペレーションエンジニアが
これらの業務を担当していると考えるでしょう。
それもそうですね。
この世界では
RPMファイルの作成だったり
EC2インスタンスの起動だったり
計測的インテグレーションツールの実行だったり
ロードバランサーの新しいマシンへの切り替えなどなど
が必要になることがあります。
フロントエンドのオペレーションエンジニアにとって
このすべてがなくなるわけではありませんが
新しいツールも出てくるでしょう。
おすすめの記事として
ワードプレスウェブサイトのデプロイメントを
改善する方法という記事があるらしくて
12:00
その記事のリンクが貼られていますので
後ほどこの記事自体
今日読んでいるやつも
ツイートしますので
リンクをたどってみてください。
フロントエンド
オペレーションエンジニアというのは
ビルドツールチェーンに精通する
ものですよと言っています。
計測的インテグレーションあるいは同様の
サーバーの運用のセットアップというのを支援しますが
より具体的にはアプリケーションが
動作するテスト用インスタンスと
最終的にはデプロイ用インスタンスのセットアップというのがございます。
Gitのポストコミットを
フックに
アプリケーションに統合し
マスターにマージする前に
ファントムJSあるいは
ソースラボやテスティング
ブラウザースタックなどでテストを
実行するのですと。
彼らはこれらのサーバーが生のコードを受け取り
いくつかのコマンドで結果のアプリケーションを
構築できるということを確認する必要があります。
と言っています。
懐かしいツールの名前がちょいちょい出てきましたね。
DodoJSは今も
主流ですけどファントムJSとか
ソースラボっていうのはかなり懐かしいですね。
本当に記事が古いからですけど
この辺のツールっていうのが
主流だったのだというのを今
読んでて懐かしく感じました。
では続いていきましょう。
最近多くの人が
グラントを使っているのはここですと。
現代のツールと読み替えてください。
グラントビルドを使えば
これらのマシンというのは適切なテスト環境を
実現するためにビルドされたバージョンの
アプリケーションを提供することができます。
グラントビルドというのは
RequiredJSのR.jsビルドツールや
ブラウザリファイですね。
のプロセスを呼び出したり
単にファイルのリストを順番にミニファイして
連結させたりすることもできます。
Webpackでも同じことができますね。
また画像の圧縮だったりスプライトの作成
その他必要または可能な方法で
リクエストの削減に加えて
CSSですね。
またお好みのプリプロセッサーの
CSSの方言ですね。いっぱいありますけど。
いわゆるオールトCSSってものですね。
に対しても同様のことが行われます。
フロットエンドオペレーションエンジニアっていうのは
人々のローカルマシンで動作するということを確認します。
簡単なグラウンドテストによって
ローカルで全てを構築し
それを提供しテストすることができます。
おそらくWebドライバーAPIと
互換性のあるサーバーを使用しますと。
WebドライバーAPIも懐かしいですね。
最近あまり目にすることがなくなった。
全然現代でも使われてるかもしれないですけど
弊社がそんなに
テストについて本格的ではなかったっていうのも
背景にありますけど。
戻ります。チームメンバーが自分のアプリケーションを
継続的インテグレーション環境にプッシュし
そこでテストする力を持つようにする
というのが目的です。
そしてデプロイインベントにおける
単一障害点を排除します。
GitHubがローンチ中にダウンしても
怖くありません。
機能ブランチとか将来のリリースブランチの
社内デプロイを容易にしましょう。
品質保証チームが簡単にテストできるようにして
マネージャーたちが簡単に
未完成のものをデモできるようにします。
アプリケーションを
複数のバージョンで構築し
それぞれのコアユーザーに
最適になるようにサポートします。
これはモバイル用や古いバージョンの
15:00
インターネットエクスプレラ用のビルドを意味しますが
これらの機能、ブラウザ、デバイスのテストに対して
プログラミングしている人には
全てが比較的透明であるべきですよ
というふうにおっしゃっています。
めでたくIEはサポートが終了になって
フロントエンドエンジニアの
一つの時代が終わったなという感じはしますけど
同じように
各種ブラウザだったりとか
各種端末ですね。
ブラウザ端末でもちゃんと動作するよね
というのを確認するような確認環境と
端末を用意しておきましょうというところですね。
ここは完全にQAの
領域とか品質の領域になってくるので
どこまでフロントエンドオプスの
人がやるかというのは
ちゃんと領域はしっかり積み分けしたり
線引きをしておくのがいいのかなと思いますけど
別にやらなくていいという意味ではないし
QAチームがいるんだったらそこにお任せしてもいいですけど
そのお任せさせる内容と
それに対しての期待値とか結果というのを
どうするかというのは
お任せしておかないとあやふやになってするので
ここはさっき門番という言葉も
使われた通りなので
できるなら自分たちでやったほうがいいなと思ったりもしますし
やる代わりにQAチームに
この辺で大丈夫だよね
みたいなレビューとかをもらうというのが
いいと思いますね。
はい。
大々にしてフロントエンドオプスの人たちが
品質の責務を持つことがある気がするので
ちょっと身が重い感じもしますが
その分
車内評価というのも
上がってくれたほうがいいなと思ったり
はい。そんな感じです。
はい。続きましょう。リリースを作成して
それを静的なHDキャッシュ型コンテンツの
配信ネットワークにアップロードし
スイッチを入れて本番稼働させるというような
プロセスを容易にしましょうと。そして
文書化された迅速なロールバックメカニズムも備えています。
おそらく最も重要なことは
全てを自動化することでしょうと言っています。
そうですね。ロールバック周りまで
ちゃんと敷地を決めて
自動的にロールバックしてくれる
というのが最高だなと思いますね。
はい。では続いていきます。
続いて
トラッキングスピードの章ですね。
に入ります。
スピードの追跡というところですね。
はい。アプリケーションのスピード
テストのスピード、ビルドとデプロイのスピード
そして他のチームメイトが
運用プロセスを理解するスピードというのが
今回対象になります。
フロントエンドのエンジニアというのは
ダッシュボードにデータを送りながら生活します。
スピードという点ではデータ王様になります。
このダッシュボードには可能な限り
多くのデータが統合されています。
最も重要なのはチームのアプリを
複数のブラウザで常に実行し
スピードに関する全ての
重要な指標を追跡することです。
このスペースには
現在多くのオプションがないため
おそらくウェブページテストの
インスタンスのプライベート
クラウドを立ち上げることになるでしょうと。
世界中の複数のゾーンに配置し
ノンストップで稼働させるのですと。
現代は結構世界中の
ゾーンに
CDNエッジは
振られていたりするので
どのCDNを使うかは別ですが
お金があるなら赤マイもあります。
かなり有名なサイトでも
色々なサイトでも赤マイは使われているので
良いのですが
やはりちょっと高いですね。
他に
18:00
AWSを使っているならもちろん
AWSのクラウドフロントを
使ったりとかもありますし
あとはファストリーさん
やはり有名なところ
早そうだという印象はあります。
とか
先ほどのクラウドフレア
もありますので
色々なCDNのサービスが
提供されているのでどれを使うかは
まちまちですが
どちらにしろ全てに見といても
ちゃんと運用できる
技術と知識がないと
導入するからには知らないといけない
というのがあるので
この辺はフロントエンドオプスの人たちの
かなり領域だと思ったりはしました。
現在はオプションがないと言っていますが
多分今はオプション全然あるんじゃないかと思いますね。
複数ブラウザで実行したりとか
スピードに関する指標を追跡するための
オプションがいっぱいあると思いますね。
次ですね。
ロード時のhttpリクエストの数というのを
グラフ化したチャートというのもあります。
またロード時に配信されたJavaScript
CSS画像のgzipの処理
および最小化されたペイロードを
示すグラフというのも用意されています。
さらにコードの解析の
効果というのを測定できるように
圧縮されていないJavaScriptのペイロード
というのも用途することができます。
モドページスピードとか
エンジンXページスピードみたいなツールも
投入して隙間に入り込んだミスを
キャッチすることもできます。
この辺はノードJS周りのツールだと思いますし
あと
ApacheとかエンジンXとかの
ウェブサーバーの
ツールだったりしますけど
その辺レベルで
確かに見てくれるなら見たいと思いますよね。
あとは最近は
ウェブパックを使っていることが多いと思うので
ウェブパックのアナライザーというのが
あります。
アナライザーは確か
今モジュール化されて組み込まれていたのかな
デフォルトで確かオプション設定
するのはいけないような気もしますが
もしダメだったらNPMからインストールすればと思います。
ウェブパックアナライザーだったかな
という名前で確かに
NPMでも公開されたりしてあると思いますけど
それを使うと
バンドルされた
ビルドコードにバンドルされたファイルを解析して
どれくらいのファイルかどれくらいのサイズなんですか
というのを一覧化してくれるんですね画像として
それも結構見てて面白いので
参考にしていただければと思います。
それだけでもバッと見て
デカいモジュールとかライブラリとかがあるんだったら
それを削るというか
他のライブラリに置き換えて
スリム化するというのも全然いい話だと思ったりしますね。
結局フロントエンダーのパフォーマンスって
最終的にはファイルを読み込まなきゃいけないので
その読み込み速度と
それを
ブラウザに解析させて
中小公分器を作るんですけど
そこから
キーを作った後にレンダリングする
処理を挟まなきゃいけないので
ファイルサイズが小さければ小さいほど
より高速になるというのは
心理というか今後も変わらないと思いますので
なのでファイルサイズを実作するために
アナライザーを使うというのも結構いいなと思ったりしてます。
戻ります。
最新の開発ツールや計測ツールを
使いこなしましょうと
開発ツールからアプリのフレームグラフとか
ヒープスナップショットを読み取ることもできますと
そのような各ブラウザならばということですけどね。
21:00
スクロールとかアニメーションの
秒間フレーム数というのも計測し
レイアウトのスラッシングを防ぎ
メモリのプロファイルというのを構築し
合成したりとかレンダリングアプリケーション全体の
ビジュアルパフォーマンスに
常に目を光らせていることでしょう。
デスクトップとモバイルのデバイスの両方で
これらを全て行い
全ての分野の傾向を追跡しましょうと言っています。
ちゃんと数字とかメトリクスを取るような
環境があるというのは大事で
それを
失礼。フロントエンドオプスの人が
担当することになるだろうなと思ったりしています。
おすすめの記事として
モバイルデバイスってウェブサイトを
高速化する方法という記事のリンクが
貼られていますね。これもちょっと古い記事
かつ多分本人の記事かな
この筆者の記事の
別の記事ですけど
高速化のお話っていうのは
多分技術的にはほぼほぼ
変わっていないというかブラウザがほぼ変わっていないから
新しい機能とかが
たくさん入っているブラウザの
コアな
レンダリング機能とか計算処理機能っていうのは
ほぼ変わっていないはずなので
これは多分今読んでも全然通じる気がするので
ちょっと気になるので読んでみます。
もし面白そうだったら明日の
朝活でも読んでいこうかなと思います。
タスクの並列化をして
タスクの並列化っていうのを徹底して行いましょう。
ウォーターフォールとか
ドットハーデータっていうのを使って
アプリケーションを追跡し全てのシリアル操作が
必要であるか意図的であるかっていうのを
確認しましょう。
テスト、ビルド、デプロイの平均実行時間を
グラフ化します。そしてそれを
低く保つために戦うのですと。
外ビーゾンのサイズと
速度をグラフ化しましょう。遅いAPIリクエストを
制御することはできないかもしれないですけど
その数が増えている理由を指摘できるように
したらいいでしょうと。
それらの数値が許容範囲を超えたら
アラームを設定しますってところですね。
今のが
トラッキングスピードの章でした。
とにかくやれることを
全部やっていく。
計測をひたすらするってことですね。
ここに尽きるんだと思いますし
計測しなければ実態は見えないので
そりゃそうだなと思ったりします。
続いて
モニタリングエラー&ログ
エラーとログ周り
のところをしっかりモニタリングしましょう。
監視しましょうってことですね。
ログを監視すること、監視じゃなくて管理ですね。
ログを管理することっていうのは
通常の運用エンジニアにとって
必要であります。
アプリケーションを実行することで
生成されるデータっていうのは
現実の世界で物事がうまくいかない場所を
理解するために不可欠ですと。
フロントエンドのオペレーションエンジニア
っていうのはクライアント側で
同じレベルのイントロスペクションを可能に
するツールとかコードも用意するでしょうと。
これは多くの場合
分析ツールとして具現化されます。
アプリケーションエンジニアっていうのは
重要なイベントや一定レベルのエラーを
ロギングサービスに記録されるように
直接にフィルタリングされ
クライアント上でバッチ処理され
内部または外部の分析スタイルの
プロバイダーにイベントとして開演されます。
まあそうね。
エンジニアはブラウザー名と
アプリケーションの展開バージョン
24:00
スクリーンサイズそしておそらく他のデータ
などなどを状況を
特定するのに十分な情報を得ることができます。
ただし個人を特定できるような情報を
ここに保存することはなるべく避けたい
って思ってますと。それもそうですね。
スタックトレースのログっていうのは
それをサポートしているブラウザーでは
非常に便利になります。これを行う
サードパーティーのサービスを統合することができます。
ログ周りは本当そうですね。
僕もバックエンドでやってることには
何かを設計するときに絶対そのログ周り
どうやって集約してどこに
吐き出すかとかログのメッセージの本文
どうするかとかは毎回毎回確かに議論してたので
ここは大事だなと思います。
フロントエンドオペレーションエンジニアっていうのは
エラーに対して非常に小さな許容範囲を
持つことを推奨します。
発生したエラーは全て調査し
修正するか別の方法でログに記録します。
戻ってくるデータを使って
ブラウザー別あるいはアプリケーションの
状態情報別にエラーの
グループを可視化できるようにする必要があります。
エラーの発生を許容する
敷地を設定して
それらを超えたらエンジニアに通知します。
その深刻度を設定して
必要に応じてバッチの提供だったりロールバックを行いましょう。
ロールバックよりもクイックバッチが
優先されると思いますが。
今日の運用担当者が
管理するシステムのセキュリティに
注力するようにフロントエンドの
運用エンジニアはXSSの
脆弱性のプローブを
持ち品質保証チームと
一緒に常にアプリの穴を探すことになります。
フロントエンドオペレーションエンジニア
は本番環境のアプリケーションの
状態を最新に把握することができます。
フロントエンドの世界では
アプリケーションが自分のマシン上で動作しないため
これは難しいことにはなりますが
だからこそより必要なことです。
最近だと
クラウドサービスでも
ローカル上で
疑似的に実験したり
試すような環境が
提供されているクラウドもあったような記憶があります。
記憶が間違っていたらすみません。
この辺は現代の技術で
割と解決し始めているのではないかと
印象を持ったりします。
バックエンドとか
全部ドッカーで管理していれば
すぐできたりするのですが
得てしてフロントエンドの人たちは
ドッカーを使わないと思ったりします。
もちろん全部ドッカーでコンテナ管理していれば
全部一元管理しているし
コマンド一発ですべてを管理できているので
そこでテストしたり
本番と同じ環境を生み出して
テストすることもできたりするので
それはいいのですが
フロントエンドでドッカーを入れるかというと
そこはまた別の議論があったりしますので
ドッカーを動かすような
ウェブサーバーを用意しなければいけないというのも
あったりするので
では続いていきましょう。
キーピング・フレッシュ&スティブル
新鮮さと安定さを保ちましょう
という話です。
私がこれまで一緒に仕事をしてきた
優秀な運用担当者が本当に得意としていた
というのは物事を常に
最新の状態に保つことでした。
アプリケーションによっては
安定性と
セキュリティの必要性が非常に高いため
注意がより優先されます。
しかしほとんどの場合
依存関係や環境を
最新に保つことに失敗をすると
アプリケーションは時間の経過ともに古くなってしまいます。
27:00
私たちはみんな4年前のプロジェクトで
すべてのツールが非常に古いバージョンのもので
そこから良いパフォーマンスを生き出すことは
不可能であるというふうに頼り組んできました。
この記者の方のサービスですね。
おすすめの記事として
ウェブサイトのパフォーマンスを低下で
トラフィックを失っていませんか?
という別の記事のリンクが貼られています。
これもまた古い記事かな。
2010年なのでもう10何年前の記事なので
ここまで戻ると
ちょっとさすがに参考になるか
怪しくなってきます。
フロントエンドオペレーションエンジニアというのは
依存関係を最新に保ち
システム内のゴミを取り除くのに効果的です。
この記事が古いので
出てくるライブラリの名前も古いんですけど
JQueryの次のバージョンが
リリースされるとき彼らはそのスキルを使って
アプリケーションの依存関係を
新しいバージョンで動作するように変更し
その変更を検証するためにテストを行うでしょう。
グラントを最新に保つ
とも必要です。
Node.jsの一緒にということですね。
これが実用化されたらアプリケーションの画像を
その形式に自動移行させるとか
その辺の必要もありますねというお話でした。
はい。
依存するライブラリのバージョンと
Node.jsも確かに最新に保つのは結構大事なことですね。
余談ですけど
JQueryって古いと言い方してしまいましたけど
全然現代でも使われていますし
現代でもJQueryというのはバージョンアップが
続けられているので
主流に使われてはいるんですけど
開発でメインのフレームワークとか
ライブラリとして使うかというのは別だからって
別にJQueryを比例するとか
そういう意味や意図は全然ないです。
使いたいかというと使いたくはないですけどね
というお話です。
はい。余談でした。
アーキテクチャの重視のアプリケーションエンジニアと
密接に連携して
システム全体が実行可能で
どの分野でも遅れを取っていないということを確認しましょう。
彼らはできるだけ頻繁にこのようなことに取り組んでいます。
構築中にあちこちの依存関係を更新することは
全てを更新するという大きな費用を
設けるよりもはるかに簡単です。
本当か?
それぞれの依存関係を更新することは
簡単ですかね?
依存している限り他のところで
バッティングして動かないとかあると思うので
簡単じゃない気がしますけどね。
言っている意図がちょっと違うんだったら
ごめんなさいって感じですけど。
ちょっと読んでいきましょう。
アプリケーション開発者は依存関係を緩やかに結合し
独自のモジュールのための
優れた一貫性のあるインターフェースを構築するよう
促されます。
オペレーションエンジニアというプロジェクトが
新しくなった後もずっとそのプロジェクトで
仕事をすることを可能にし楽しませてくれますよ
と言っています。
でも先のことを考えると
オペレーションエンジニアというのは
自分が関わらなくなったとしても
同じようにできるように保つのが結構大事
ことかなと思いましたね。
もちろん長く関わっていくんだったらそれで構わない
という感じですけど。
ただそこまでいくとフロントエンドなのか
というと本当に
DevOpsに移行しているような気もしたりはしますけどね。
それはそれで別にいいと思います。
エンジニアのキャリアとして
フロントエンドに留まらないでオフスマーリを
できるって言うんだったらそれは本当に強いことだと思うので
やっていくのは
いいと思いますね。
今後の課題です。The Futureですね。
30:00
これで最後かな。
このようなタスクは何年も前から行われてきたことであり
チーム内のすべての開発者の
関心事であるべきだと
多くのコメント記者が私に言うでしょうと。
私はこの2つの意見に賛成です。
私は新しい概念を導入しているわけではなく
私たちが何年も行ってきた作業をまとめて
それに名前を付けているのです。
そうすることで将来より良いツールを作り
より良いプロセスを
文書化することができるようになると思っています。
この役割をチームに加えたからといって
他のメンバーのパフォーマンス責任が
免除されるわけでもありません。
ただ、今私が出会ったほとんどのチームでは
フロントエンドのオペレーションは
誰も明確なプライオリティを持っておらず
そのためいざという時に手を抜かれることが
多いのですと。つらいですね。
特にツールの設定や監視というのは
フロントエンドエンジニアの通常の仕事とは別に
この役割を正当化できるほど
やれることがあると思います。
最も重要なことはこれらの作業が
新しい仕事が生まれるかどうか
あるいは別の方法で問題解決できるかどうかに
関わらず、何らかの方法で
これらの問題を解決することの
重要性を全員が意識する必要がある
ということになります。
大事ですね、これは本当に。
これらの問題を無視しても
信頼性が高く堅牢で高い操作性を持つ
アプリケーションを実現することは
おそらくできないでしょう。
これらの問題に対処することは
アプリケーションの安定性と寿命、そして
プログラマーとユーザーの幸福のために
非常に重要になります。
このことを念頭において構築すれば
Webの勝利につながり、私たち全員が
Webの勝利を願っているのですと言っています。
以上で記事は終わりましたが
いかがだったでしょうかね。
僕はやっぱり古い記事だったんですけど
全然今でも通用する記事だったな
というのは改めて感じましたね。
出てくるツールとかは
現代のものに置き換えても
全然その通りだなという記事が多かった
感想だった。
なおかつ、やっぱり昨日の記事でもそうですと
やはりフロントエンドって本当に
複雑化の意図をたどっているので
ちゃんと役割明確にするというのが
重要だと思いましたね。
一言でフロントエンドエンジンにあって
名乗るのはもうつらいなというのは
僕もすごく感じているところで
世界でもフロントオブフロントエンドと
いうワードが出ているくらいですし
それでもまだちょっと抽象的とか
責務が多いなという話があって
その辺が昨日読んだ記事だったんですけど
このDevOps周りの
話ですね
フロントエンドオプスというところだけでも
エンジニアとして
専門職として切り出すことは
僕は割と賛成派ですね。
やっぱりそこ弱いと
各社やっぱり弱い分
そこにちゃんと専門化して
強みを作っていくというのは結構大事だと思います。
別にちゃんと体制組まれている会社だったら
それは全然いい話なんですけどね。
というところでした。
ただ一方でそのエンジニアを
立てるのは結構ですけどちゃんとアプリケーションエンジニアとか
QAチームの人たちとかと連携できる
というところも重要なので
何やかんやフロントエンドの知識
というのも必要にはなると思うので
開発した人がやっていくのがいいんじゃないかなと思ったりします。
あとやっぱり気になるのは
切り分ければ切り分けるほど
関係部署が増えるということになるので
結果コミュニケーションの数が100%増えるんですよ。
33:00
なのでコミュニケーションスキルがある人というのも
結構重要なのかなと思ったりします。
やっぱりどこまで行っても
僕らビジネスするときは人と一緒にビジネスをするので
コミュニケーションスキルというのは
エンジニアとか関係なしに
全ての社会人にとって必要なスキルなんだというのが
改めて突きつけられた感じがしますけど
コミュニケーション苦手なところもあるので
頑張っていきたいなという風に感じました。
というところで
今日の朝勝は以上にしたいと思います。
今日もご参加いただいた方
たくさんありがとうございました。
明日もゆるーく何か別の記事を
読んでいこうと思っていますので
興味があればご参加いただければなと思います。
1週間の中日、水曜日ですね。
もう月末が近づいているので
いろいろお忙しい方もいらっしゃると思いますけど
今日も一日頑張っていきましょう。
ではお疲れ様です。
