エンジニアやってて知らなかったことをまとめていく
はじめに
fujiokaです。
ここでは、自分がプロジェクトや自主学習で出会った、
エンジニアの専門用語や概念を、調べてメモしていきます。
(自分用の管理で、上に追記していきます。)
共通系
ピアリング [2022.6.26]
リッスン(listen)[2022.6.26]
システム系
構築ツール [2022.6.10]
- Orchestration
- Dockerはアプリ環境をデプロイ、ポータブルさせることが目的であるのに対して、k8sはコンテナ管理(特に複数のコンテナをまとめ上げること)を目的とする。
- クーバ
- Bootstrapping (OSレベルの設定)
⇒AMIのイメージ- ただし、Dockerのようなコンテナとは異なる。
コンテナはまるっと新しい環境を作るので、デプロイを目的としたポータビリティを有する。
- ただし、Dockerのようなコンテナとは異なる。
- Docker、Vargant
- Configuration (ミドルウェアレベルの設定)
⇒OSのための設定のイメージ- Linuxなどのシステム設定をTuneするための管理ツール。
つまりこれを使うことで、サーバー環境などを統一化することができる。
- Linuxなどのシステム設定をTuneするための管理ツール。
- Ansible, Puppet, Chef
クラウド系
CORS [2022.3.10]
- クロスオリジン設定。つまり、オリジンサーバー以外の手前から、データ・処理を受け取ることができるようにする設定。['22.04.30]
⇒つまりキャッシュ利用になる。そのため、Cacheの設定が必要。
Route53リゾルバ [2022.6.26]
Web系
ブラウザオブジェクト・DOMオブジェクト [2022.5.1]
- JSには、ブラウザでのウィンドウ操作、ページ遷移や履歴、印刷ダイアログ表示などのブラウザならではの操作をするモデル(ライブラリ的機能)を有している。['22.04.30]
参考:ブラウザオブジェクト - 第2章 JavaScriptのオブジェクト - [SMART]
DB系
データベースを決めるまでの流れ [2022.6.25]
Excelで闇雲に書き出すのではなく、セオリー通りのプロセスで作ってこそ、
手順正当性が担保されて、要件の難易度に関わらずに、クオリティがキープされる。
- 要件をできる限り明確にする
(そのサービスは何が肝なのか? 低レイテンシか、スキーマの柔軟性か) - 候補となるDBサービスの特性を調べる
- ER図を書く
- アクセスパターンを洗い出しする
- データ自体の特性について分析する
読んでみた(詳解! Google Apps Script完全入門 [第3版])Part2
- はじめに
- 第8章:SpreadSheet(SS)
- 第10章:GoogleDrive(GD)
- 第16章:Baseサービス
- 第17章:ユーザーインターフェース
- 第18章:
- 第19章:
- 第20章:
- 第21章:
- 第22章:外部サイトへのアクセス
- 第23章:ライブラリ
はじめに
Part1に続いて、GAS本格入門を読んだので、まとめてみました。
Part1では、GASの基礎のキソや、JavaScriptに依る基本機能についてです。。
今回のPart2では、Googleサービスとの連携に関する詳細機能についてまとめます。
第8章:SpreadSheet(SS)
- SSの各クラスは以下の階層構造になっている
- SpreadSheetApp
- SpreadSheet
- Sheet
- Range
- getActiveSS/Sheet/Rangeで、対象をセットする。
ただし、GASは実行時間が遅い既知の事実があります。
そのためコンテナバインド型の場合には、
SSAppクラスとSSクラスを順々に読まずに、getActiveSheet()をそのままセットすることで効率的に実行できる。 - SSに限らずサービスでは、URLがあれば、そこからIDを取得できる
- 表の利用はできるだけA1セルから使うのが良い
(getRangeする時のための読み込み効率化) - 値の設定
- setValues:値を書き込む
- setFormula:数式を書き込む
- GASで作成した関数をSSからコールして利用することができる
(※その際は大文字で表記する)
第10章:GoogleDrive(GD)
- GDの各クラスは以下の階層構造になっている
- DriveApp
- Folder
- File
- 上記以外に反復処理用に、
FolderIteratorとFileItaratorが存在する。 - フォルダ/ファイルを以下の条件で検索して取得することができる
- title
- parents:親フォルダのフォルダID
- メールアドレスをキーとして、
指定のドライブにおけるフォルダ/ファイルに対して、アクセス権付与ができる。- FileObject.addEditor
- FolderObject.addEditor
第16章:Baseサービス
- console、logger、Browserなどの基本機能を受け持つクラスが用意されている。
- logger :Pythonと同じ(log、info、warn、error)
- User、Session:アカウント情報などを取得できる
第17章:ユーザーインターフェース
- SSでも、getUiすることで、alertメソッドが利用できる。
- つまり、ダイアログ表示が簡易的に実現できる
- 「はい/いいえ」「OK/キャンセル」などボタン埋め込みもできる
- 入力ボックスも作れる
第18章:
- 論理
第19章:
- 論理
第20章:
- プロパティには3種類ある
- プロパティの設定例
- const xxxProperties = PropertiesService.getXxxProperties();
xxxProperties.setProperties = {"key": "value"};
- const xxxProperties = PropertiesService.getXxxProperties();
第21章:
- SciprtIDは、コンテナバインド型であることから、
設定ファイルでの管理ではなく、ScriptAppクラスを定義したのちに、getScriptIdするのが良い。
第22章:外部サイトへのアクセス
- Url Fetchサービスで、HTTPリクエストの送信やHTTPレスポンスを解析することができる。
- UrlFetchApp:送信クラス
- HttpResponse:解析クラス
- 以下のfetchメソッドを使い分ける
- fetch:Return=HttpResponse
- fetchAll:Return=HttpResponse[]
- getRequest:Return=リクエストを示すObject
- HttpResponseクラスに対しては、以下のメソッドが利用できる
- getResponseCode()
第23章:ライブラリ
- 論理
その他
- コンテナバインド式なので、SSAppではなく直でgetActiveSheet()する。
- フォルダ/SSへのアクセス権限付与も合わせて行う。
- appscript.json
- TIMEZONEを付与すること。
読んでみた(詳解! Google Apps Script完全入門 [第3版])Part1(JavaScript基本機能)
- はじめに
- 第0章:前提
- 第1章:GASの注意点
- 第2章:プロジェクトとスクリプト
- 第3章:(JSの)基本構文
- 第4章:(JSの)制御構文
- 第5章:(JSの)関数
- 第6章:(JSの)クラスとオブジェクト
- 第7章:(JSの)組み込みオブジェクト
- その他
はじめに
こんにちは、fujiokaです。
ついに始まりましたね、10連休のゴールデンウィーク..!🏖
そんな中でもまだまだコロナ禍の影響もあるので、
ジョギングしたり🏃🏻♂️早く寝たりと健康的に過ごしたり、
家でまったり過ごそうと思っています
連休でまとまった時間が取れるので、
昨年に続いてプロジェクトで利用している(※過去ブログ)、
GoogleAppsScript(GAS)を腰を据えてGASを体系的に学習しました😆
これまでは、必要な機能をその都度Webサイトで調べながら作っていましたが、
開発が膨れてきて、
「GAS特有の機能を使ったら、実はもっと効率的に書けるんじゃね?🤔」
と思い、今更ながら、専門書を読んでみたので、まとめてみました。
(まずは各章のポイントをピックアップしていきます)
第0章:前提
普段プロジェクトで使っている略記を用いて、以降をまとめていきます。
-
- SS:SpreadSheet
- GD:GoogleDrive
第1章:GASの注意点
- GASは、ガスと読む。(ギャスではない)
- GASは、13のGoogle Appsと連携できる。
⇒Advanced Google Serviceを使うと、20以上のサービスと連携できる。 - ブラウザオブジェクトとDOMオブジェクトは利用できない。
- GASには、制限&クオータがある。(P23)
第2章:プロジェクトとスクリプト
第3章:(JSの)基本構文
- 基本構文
- 変数:let ⇒V8ランタイムをオンにしていればvarでなくてOK
- 定数:const
- 記法
- キャメル ⇒ メソッド、変数/定数
- スネイク ⇒ グローバル定数、プロパティのキー名
- 文字列
- console.log('this is ${val}') (Pythonで言うf文字列)
- 配列
- ...{list} (i for i in list と同じ)
第4章:(JSの)制御構文
- 論理演算子
- ”==”と”===”は異なる。
- ”==” :データ型は考慮せずに比較する
Ex) ”10”==10 ⇒ Trueである - ”===”:データ型を含んで比較する
- ”==” :データ型は考慮せずに比較する
- AND:&&、 OR:||、 NOT:!
- ”==”と”===”は異なる。
- 条件分岐(Switch)
- Switchは、break が無いと、全ケースを通過してしまう。
switch() {
case "case1" {
console.log("this is case1");
break
} case "case2" {
console.log("this is case2");
break
} default {
console.log("this is default")
}
}
- Switchは、break が無いと、全ケースを通過してしまう。
- ループ文
- while
- for (let i = 1; i < 5; i++) {}
- for (i of list) :配列に使用(値で回す)
- for (i in object) :オブジェクトに使用(キーで回す)
- ループにラベルを貼って、任意のループをbreakすることができる
第5章:(JSの)関数
- プライベート関数には、末尾にアンスコを1つ付ける(Pythonと逆)
∵コンソールでのプルダウン関数検索から除外するため - GoogleのJSスタイルガイドでは、privateもprotectedも、末尾アンスコらしい。
- (Pythonと同じではあるが、)
変数をイコールでコピーした場合には、それぞれ別メモリとして値が管理される。
(いわゆる値渡し)
一方で、配列/オブジェクトの場合には参照渡しが起きるので、
値渡しの場合には以下のようなコードが必要。
let arr2= arr1.concat();
- JSのドキュメンテーション(コメント)は、以下を参考にすること。
- アロー関数を利用することで、いちいちfunction 〜〜と書く手間を減らすことができ、コードの軽量化ができる。
ただメソッドレベルの作成は、リテラル関数かメソッド定義が望ましい。(P.155) - グローバルに定義しているものは、ファイル上に集めること。
∵
第6章:(JSの)クラスとオブジェクト
- JSにおける、プロトタイプ
- 各インスタンスで、プロパティは個別にあって良いが、メソッドは1つで十分
(それぞれに定義する必要はなく、どれか1個あればOK)
- 各インスタンスで、プロパティは個別にあって良いが、メソッドは1つで十分
- クラスは、以下の通り
class ClassName {
constructer(param1, param2) { ⇦
this.val1 = param1;
this.val1 = param2;
}
someMethod {
(something is occured);
}
}
第7章:(JSの)組み込みオブジェクト
- V8ランタイムに設定しないと利用できないStirngメソッドやArrayメソッドなどが多数ある
(Ex. StartWith、repeat) - Arrayメソッド
- アクセサメソッド
- push ⇄ shift:配列の後・前に値を追加
- slice、splice:インデックスを指定して配列を抽出・置換する
- アクセサメソッド
その他
- GASには以下がある。
- 改善案
- ボタン押下ではなく、定期投入に変える?
- Googleのコード規約に合わせて修正する。
- プライベートメソッドには、末尾にアンスコを付ける。
- クラスが利用されていないので、使用する
- AWSへの送信オブジェクトを、クラス化する
- 例)生産者の登録オブジェクト
class RequestObject {
constructor (tenant_id, tenant_name, detail) {
this.tenant_id = tenant_id;
this.tenant_name = tenant_name;
this.detail = detail;
}
}
- 例)生産者の登録オブジェクト
- AWSへの送信オブジェクトを、クラス化する
- ループの基本記法を決める
ブータン滞在記 2019.3
はじめに
ついに来ました😲!!!
これまで大学院での研究ターゲットとしていた、
ブータン🇧🇹における、氷河や河川、水力発電所を、
ついに自分の目で生で見る機会です!
研究室の後輩と、ブータンに関する研究を一緒に取り進めていた先生たちと
一緒に訪問させていただいてます。
(下のリンク先で、同行した後輩にブログを書いてもらってます)
DAY1 2019.3.13
窓からエベレストやカンチェンジュンガが見えた。レアらしい。
(カンチェンジュンガは、世界で3番目に高い山⛰なんですよ...!)
昼から早速エマダツィを食べる。辛い。代々木で予行練習してよかった。
(代々木に日本唯一?のブータン料理屋がある。一度食べておくと、辛さのトレーニングになります。)
以前来日してもらった、ブータン政府の研究員であるノルブさんらと、
半年ぶりに再会^^
ゴ服がカッコいい。
役人さんは皆着ているが、街では洋服を着ている人が6割くらい。
(ゴ服は正装なので、決して安くはないらしい)
DAY2 2019.3.14
NEC(national env. committie)、forest,engineering、水文気象センターへ訪問した。
お話を伺うと、化学肥料など、あらゆるwasteについての懸念があるようだ。
ブータンの人は、海外のリソースは使ってやろうという貪欲さがいい。
あと、英語が非常にうまい。見た目との大きなギャップがあった。
街中はほとんど英語表記。みんな英語が通じる。物価の安さに驚く。
ご飯は400円くらい。
DAY 3 2019.3.15
水力発電所を見学した。
やはりエネルギー機関は国の重要施設らしく、守りが堅い。(当然写真はない)
私は次の4月からはゼネコンで働くことになったので、
ブータンにはどんなインフラがあると良いか、と質問した。
すると、谷を渡るための橋が欲しいらしい。
(空港首都間のトンネルは、技術的に難しいらしい。)
DAY4 2019.3.16
発表を行う。トークスキル、内容うんぬんよりも、リスニング力が下がっている。
(何を質問されているかがキャッチ難しい)
良書と言われる「OREILLY『入門 監視』」をまとめた
はじめに
2021年末から、プロジェクトで私が開発しているサービスが、
ベータ版としてエンドユーザーに利用され始めるようになった。
まだユーザー数も利用頻度もボチボチではあるが、このタイミングで、
「ユーザーのアプリ利用は正常に動作しているか?」あるいは、
「そもそも、ユーザーはどの頻度・時間でサービスを使っているのか?」
といったことを検知・検出するための運用監視が必要なフェーズになっている。
将来的にサービスがスケールする前に、
運用監視のファーストアクションとして、CloudWatchダッシュボードを利用したサービス利用状況の可視化・監視を行う。
運用監視を学習するためのファーストアプローチ
恥ずかしながら、「運用監視…ナニソレオイシイノ?」状態の私であった。。。
そのため、上司にまずはこの書籍を勉強することを勧められた。
かなり良書かつ、ややとっかかりにくいとのことなので、
以下2点に注力して、書籍をまとめる。
・運用監視をやる上で外せない必須部分
・プロジェクトで利用できる実用的な部分
「入門 監視」まとめ
読んでみた結論
- 監視にも定石があるので、それに沿ってやること。
・定石はツール利用による監視であり、簡便にツールで済ませるのがGood。
(※とはいっても開発が必要な場面はある) - 見えたいものが見えるグラフ、知りたいことを通知してくれるアラートを正しく設定すること。
・閾値や統計の設定は、何をどの頻度でみたいかが重要。
・「ダッシュボード作りました!」
⇒「で、何がわかるの?どう見たらいいの?」にならないことが重要。 - 監視対象のサービスに対して、ビジネス、フロントエンド、アプリケーション、サーバー、ネットワークのどの面から監視するか、多角的に設計すること。
・サービス全体を見ることで、総合的にサービスを監視できる。
⇒薄くみる。かつ、重要な点は厚くする。
主に読んだページ
- 各章の導入&まとめ
「監視の原則(第Ⅰ部)」
-
- アンチパターン/デザインパターン
監視をシステムに導入する上でまず重要なことは、”定石”、つまりアンチパターンとデザインパターンを知っていることである。
(開発然り、定石通りにやらないことで、汎用性が失われて継承や共通化の障壁になる。)■アンチパターン
・監視が運用における”杖”にならない
・ツール依存
■デザインパターン
・マイクロサービス的に組み合わせ可能
・目的由来に構成される(ユーザー視点や顧客視点など)
・継続的に改善できる(後から手が入れられる) - アラート、オンコール、インシデント管理
以下を見直しながら、運用監視はやっていく。
・通知方法は適切か?
・アラート検知した場合の手順は明確か?手順書化されているか?
・検出の方法、閾値の設定は適切か?
・オンコールの体制は適切か?(特定のメンバーに負荷は大きくないか) - 統計
アクセス頻度などに応じて、適切なインターバルでメトリクス表示する。
(日単位での平均値や合計値で、本当にみたい現状は監視できるか?)
- アンチパターン/デザインパターン
「監視戦略(第Ⅱ部)」
- フロントエンド監視
・監視対象のトラッカーによって、2種類の監視方法がある。
①ホワイトボックス監視
②ブラックボックス監視
・特にロード時間を見る。
⇒読み込みに時間がかかると、顧客の満足度やアクセス数は大きく下がる。
・SaaSで監視するのがベスト。ググればOK。 - アプリケーション監視
・3層アーキテクチャの中間
(プレゼンテーション-アプリケーション-DB)
・StatusCodeでアプリの正常動作が行われているかを監視する。
(healthエンドポイントパターン) - その他、PJでは使わないが重要な監視
- ビジネスの監視
・顧客がやりたいことを実現するのが目的ならば、
顧客をターゲットにするのが筋。
Ex.)月次収益、コスト、顧客獲得単価、など
・ユーザー個別にフォーカスしてはいけない。
(ユーザー01がMax、みたいな明示的な情報を載せてはいけない。)
あくまでも、最大/最小や、上位帯/下位帯などで、傾向を見る。 - サーバーの監視
・CPU、メモリ、ディスクなどの使用率をトレースするのが定石。 - ネットワークの監視
- ビジネスの監視
終わりに
サービスの現状を踏まえると、アプリケーション監視、プラスでビジネス監視が使えそうと感じた。
アプリケーション監視については、サービスを担っているのがAWSであることからCloudWatchダッシュボードでのデータ投入状況(投入はどのくらい行われているか、成功/失敗しているのか)をターゲットとする。
(後続の加工処理をどこまで監視するかは、工数を見ながらの相談になりそう。)
一方でビジネス監視は、より細かく投入データにフォーカスして、どのユーザーが投入しているかを解析することで、「誰が太客になり得るか」ということをサービス管理者に伝えることができて効果的になる。
⇒直接的な要望ではないけれど、
その他メモ書き
- 監視は役割ではなく、スキル
⇒システムの目的を知らずして監視はできない。つまり監視は、「動いているか」を知るための、開発に必要なスキルの一つである。 - 監視は、あるシステムやそのコンポーネントの振る舞いや出力を観察して、
"継続して"チェックすること。
⇒1回アラートをキャッチできればOK、という訳ではない
ローカルPC(Mac)でJavaScriptファイル実行環境を構築する
はじめまして、Atsushiです。
最近PJでGAS(Google Apps Script)を使うことになっため、
JavaScriptを使う機会が増えました。
JSを業務で使った経験が浅いのもあって、
自宅PCにJavaScriptをローカル実行できる環境を用意してみます。
- 0. 前提
- 1. OSからNode管理ツールを決める
- 2. Nodebrewをインストール
- 3. Nodebrewで、対象のNodeをインストール
- 4. パス・インストールしたNodeを設定する
- 5. NodeコマンドでJSファイルを実行する
0. 前提
以下のJavaScriptファイルを実行することを目的とする。
#test.js
console.log('test is passed')
Macのバージョンは以下の通り。
バージョン11.6(Big Sur)
1. OSからNode管理ツールを決める
本記事ではJavaScriptをローカル実行する方法として、
JavaScript実行環境の「Node.js」を使用します。
Node.jsを選ぶ利点としては、
実際の開発現場でも多く使われている、大規模・小規模どちらの処理にも対応していることでしょうか。
Node.jsについて詳細を知りたい人は、以下の記事も参考にぜひ。
使用するPCに応じて、Node.jsのバージョン管理を行います。
Windows⇒Nodist がオススメ
Mαc ⇒Nodebrewがオススメ
私はMacユーザーなので、Nodebrewでインストール・設定しました。
2. Nodebrewをインストール
brew install nodebrew
3. Nodebrewで、対象のNodeをインストール
以下コマンドでインストール可能なバージョンを確認する。
nodebrew ls-remote
以下コマンドでインストールを実施する。
nodebrew install-binary {対象のバージョン}
nodebrew install-binary stable (安定版のバージョンを自動選択)
インストールが成功せずに以下のエラーが出た場合には、
nodebrew setup
を実施した上で、再度インストールする。
Fetching: https://nodejs.org/dist/v16.10.0/node-v16.10.0-darwin-x64.tar.gz
Warning: Failed to create the file
Warning: /Users/{ユーザー名}/.nodebrew/src/v16.10.0/node-v16.10.0-darwin-x64.tar.gz:
Warning: No such file or directorycurl: (23) Failed writing body (0 != 1120)
download failed: https://nodejs.org/dist/v16.10.0/node-v16.10.0-darwin-x64.tar.gz
4. パス・インストールしたNodeを設定する
NodebrewでインストールしたNodeのバージョンを利用するために、以下コマンドを実行してください。
nodebrew use {インストールしたバージョン}
さらに、パスを設定します。(書き込みするファイルは、OSバージョン、個人の設定に依るので、書き換えて実行してください。)
echo 'export PATH=$HOME/.nodebrew/current/bin:$PATH' >> ~/.zprofile
以上でインストール完了です。以下コマンドでバージョンが一致していることを確認しましょう。
node -v
5. NodeコマンドでJSファイルを実行する
ローカルに作成しているJSファイルを対象に、以下コマンドを実行できることを確認してください。
node test.js
> test is passed
以上で完了です、お疲れ様でした。