結果
ブログ
目標：月 8 回（週2回）更新
結果：月 6 回 更新
読書
目標：月 1 冊
結果：月 2 冊
反省点など
ブログ月8回更新には届かなかったですが、だんだんとリズム取り戻せてる気がします。
仕事で調べものするときとか、外向きにできるものはするなど習慣づけていきたいと思います。
来月に向けて
試験勉強しているのでまた7月はペース落ちるかもですががんばります。
【読書メモ】Amazon Web Services 定番業務システム14パターン 設計ガイド
Amazon Web Services 定番業務システム14パターン 設計ガイド
- 作者:川上 明久
- 発売日: 2018/09/28
- メディア: 単行本
目次
［基本編］
- 1章 Webシステム
- 2章 ストレージシステム
- 3章 データ分析システム
［応用編］
各章1〜4個、計14パターンのサービス構成、設計についての考え方について書かれています。
1パターンだいたい15ページ前後で15〜30分くらいで読めるので細切れにでも読める感じ。
細かい設定値の話はなく、サービスの選定〜どういった機能を使うかを説明されています。
サービス自体についての説明、各パターンでの構成図についても触れているのである程度の初心者の人にも分かりやすい内容かなと思いました。
良かった点
- 構築パターンがたくさんのってる
AWSのサイトの事例にもなんとなく使っているサービスやどういう考えで使ったかみたいなことは書かれていますが、クライアント視点の話ではあるので、開発者目線で書かれている内容となるとやっぱりこういう本になりますね。
本の構成やパターンの幅も、最初はベーシックなシンプル構成からだんだん複雑にはなっていきますが、サービスの概要が事前に分かっているとこれこういうときに使うのかあーみたいな発見がたくさんありました。
- 実際の案件でのサービスの利用のされ方がイメージしやすい
個人的にはファイルサーバー（パターン6）の特にEFSが実際の利用イメージが湧いてなかったので、そのパターンが一番身になった学習でした。
試験対策ばかりしていると文字面ばかり追いがちなので、前提としてどのような思想や考えがあって、構成とサービス間の連携をどのようにするかみたいなインフラエンジニアの頭の中身を覗けているようで楽しかったです。
惜しい点
- 少し内容が古い
書籍なのでしょうがないのですが、2018年10月の本なので2年もすれば結構サービスや機能の移り変わりもあるよなあという感じの内容かなと。
アイコンも古いバージョンなのでなつかしみがあります。
Lambdaの実行時間など設定上限やコストが古いくらいで基本の基本のところは変わっていないと思うので、めちゃ気になったという点でもなかったですが。
あとシステム構成に関しての本なので、この本に書いてほしいという内容ではないのですが、
アカウント管理についての考え方みたいなこともこのアプローチの仕方で書かれているものを読んでみたいなと思いました。
まとめ・感想
資格のレベルでいうとSAA〜SAPの間くらいかなと思います。今の自分の知識でちょうどいい感じでした。
ただ実際に手を動かしてみてるわけでもないので、これで構築できるかはまた別の話な感触です。
ここ最近の2冊でぼんやりとしていたインフラエンジニアの仕事や考えていることが分かっている気がしています。
次は 資格本 注文しているので読んでみようかなとおもっています。SAPの模擬試験などの試験勉強的なことがまったく進んでおらず、そろそろエンジンかけないとなあと思っております。
（ Security Specialty 対策本 もこんどでるみたいですね・・ ）
最近のエディタまわりの環境
社内勉強ネタですが、まとめのために書いてみようと思います。
自分の設定なので良し悪しあると思います。
基本的には下記の記事が設定や選定のベースになってます。
- Visual Studio Code の初期設定など
- Sublime Text の独自スニペットを Visual Studio Code に移行
- 【VS Code】 ワークスペース
.code-workspaceを使おう
目次
VS Codeのワークスペース
VS Code 上でプロジェクト単位で作業を分割できる？機能です。
- 都度都度「フォルダを開く」からフォルダを選択しないで済む（他の案件の切り替えが多少しやすい）
- ファイルや単語の検索は自動的にプロジェクト配下にデフォルトでフィルターされる
- 拡張機能をワークスペースごとにインストール/アンインストールできる（状態も保存される）
- Gitで .code-workspace を管理すれば、複数人で環境を共有できる（プラグインなどできないかも？）
設定方法： 【VisualStudioCode】ワークスペースとは？
{画面共有}
VS Codeのプラグイン
# codeコマンドで一覧表示--- # https://qiita.com/koshilife/items/3ed4b1c28de233f39ebb $ code --list-extensions | xargs -L 1 echo code --install-extension
言語拡張やスニペット
これはバッティングするものもあるので、テンプレートエンジンなどは常時有効化はしない。
HTML & HTML テンプレートエンジン
JavaScript & JSフレームワーク
PHP & WordPress
あんまり実際に入れてていいことないのかも？
補完候補でても無視することもしばしば。
フォーマッター（コード整形）やスペースの表示
これもGulp Taskでやっている場合がほとんどなので常時有効化はしない。
zenkaku は全角スペース、Trailing Spaces は半角スペース可視化用。
タグ・属性・値などの入力補完
Auto Close Tag は勝手に閉じタグ補完。
Auto Rename Tag は勝手に閉じタグ（開始タグ）も変更。
vscode-input-sequence は連番入力の補完機能です。
その他
Japanese Language Pack for Visual Studio Code
日本語訳パッケージ
Live Share
ペアプログラミングなどに使えそう（実際に使ったことはない）
Live Server
ローカルサーバーを編集しているディレクトリをルートとして立ち上げ&ライブリロード。
GulpやSassを使わないけど、絶対パスで書かれているファイルプレビューみたいなことに便利（ほぼ機会ないけど）
Partial Diff
差分表示。difff《ﾃﾞｭﾌﾌ》 もよく使いますが。
Zeplin
Zeplinと連携。最近のですが、単純にエディタの左カラムにZeplinのアートボードリンクが増えるだけだった。
ほかに便利なものなどありましたら教えて下さい。
{画面共有}
VS Codeのユーザースニペット
ユーザースニペット機能を使っています。（メンテナンスあんまりできていませんが・・・）
例えば、
- .scss の
inc（@includeの補完） - .php の
postmeta（投稿情報取得の補完）
など。
疑似要素や背景画像周りは mixin などにしたほうがいい場合のほうが多いので最近はあまり使っていないです。
設定方法： VsCodeのスニペットのススメ - Qiita
{画面共有}
Dashでのスニペット管理
Dash アプリでもスニペット管理しています。
こちらも本来はコード貼り付け用のツールですが、どちらかというとよく使うコードのメモ帳感覚で使っています。
HTML/CSS/JS/PHP（WordPress）、よく使うコマンド（SSH接続、IP確認）など。
{画面共有}
本当はやりたいこと
Finderで一括でプロジェクトセットを開きたい
VS Codeのフォルダ機能をあまり使わずイチイチFinder見てる派なのですが、これを一気に開けたら便利かなと。
プロジェクトセットと言っているのは、htmlやscssやimg、jsフォルダごとにタブで開いている状態です。
{画面共有}
2020年前期のWebサイト
2020年前期分です。
RSSでギャラリーサイト購読して気になったのはPocketでブックマークのなかから選んでます。
まとめて見る機会はあまりないのですが、並べてみると結構偏ってたので趣向別で分けてみました。
イラストや手書き文字、きれいなメインビジュアル（映像）に偏ってます。
どれもクオリティ高くお金もかかってんだろうなーって感じがします。
VueやNuxtもこのようなWebサイトで使われる機会も増えてる感じですね。
イラスト
ウェルナビ | 日清製粉グループ
https://www.nisshin.com/welnavi/
株式会社Roots
丸の内インフラストラクチャー株式会社
https://www.marunouchi-infra.co.jp/
醸す 造る 播磨
シェフのおいしいつながり | 一般社団法人 自然と自然派
ビジュアル
The Okura Tokyo ウエディング
https://theokuratokyo.jp/wedding/
採用情報｜山﨑建設工業株式会社｜人と生きる建物をつくる建設企業
https://www.yamazaki-kk.jp/recruit/
【公式】瀬の本高原ホテル
いろは保育園｜熊本市中央区水前寺の企業主導型保育園
その他
Corentin Bernadou
https://www.corentinbernadou.co/
Diesel Wynwood ⏤ Condominium
TRANS BOOKS DOWNLOADs | TRANS BOOKS
Nuxt.jsのWebアプリをFirebase(Cloud Functions/Firebase Hosting)でSSRする
URL: https://nuxt-firebase-demo-1355e.web.app/
GitHub: https://github.com/yuheijotaki/nuxt-firebase
SSRなのでFirebaseの Cloud Functions と Firebase Hosting を使います。
AWSでいうと
Cloud Functions は Lambda、
Firebase Hosting は S3
という扱いですかね。
色々な記事見たのですが、手順としては firebase functionsでnuxt.js v2.11.0をSSR - Qiita が比較的新しくこの通りでできました。
他にもこの手の記事はたくさんありますが、
Nuxtのビルドフォルダなどディレクトリ構成がごっちゃになったり、そもそもSPAのものだったり、人によってWebアプリ作成とFirebaseの設定順が違ったりするので、とりあえず1記事でデプロイまでできる状態に持っていってから調整するところ調整したほうがいいかなと思います。
下記おおまかな手順です。
事前準備
リポジトリ作成。nodenvなどでnodeのバージョンは10系に合わせる。
functions側（Cloud Functions）のNode.jsでローカルと同じように動かないと詰まることになるので、今の所10系が安定していそう。
create-nuxt-app
Nuxtアプリを作ります。
starter-template だとうまくFirebase連携がうまくいかなかったという記事もあったのでcreate-nuxt-appがおすすめ。
モジュールとかリンターは好きなようにしてOK。
後でも変更可ですが Choose rendering mode Universal は SSR で。
作ったら nuxt.config.js の buildDir を functions/nuxt にしておく。
Firebaseプロジェクト作成
コンソールから「プロジェクトを作成」 https://console.firebase.google.com/?hl=ja
アナリティクスはとりあえず無効にしておく。
Authentication や Database などいろいろ入ってますが使うのは Hosting と Functions。
firebase init
ここからはCLIインストールして操作
https://firebase.google.com/docs/cli?hl=ja
Mac npm だとうまくいかず curl でインストールした
$ curl -sL https://firebase.tools | bash
ログイン
$ firebase login # ブラウザで認証後 Success! Logged in as XXXXX@gmail.com
ブラウザでFirebaseとの紐付け後にCLIのログインが確認される。
プロジェクトリストの表示
$ firebase projects:list # さきほど作ったプロジェクト名が表示されればOK
プロジェクトのFirebase初期化
$ firebase init # Which Firebase CLI features は 2つ選択 ◉ Functions: Configure and deploy Cloud Functions ◉ Hosting: Configure and deploy Firebase Hosting sites # さきほど作ったプロジェクトを選択 ? Please select an option: Use an existing project ? Select a default Firebase project for this directory: nuxt-firebase-demo-1355e (nuxt-firebase-demo) i Using project nuxt-firebase-demo-1355e (nuxt-firebase-demo)
functions 設定
・firebase.json
rewrites function を nuxtApp に
・functions/package.json
node のエンジンを 8 → 10 に
axios と dotenv のモジュール追加
・functions/index.js
Express つかってSSRするように設定。ここはコピペしました。
デプロイ
# ビルド $ npm run build # ローカルでデプロイ内容確認 $ firebase serve http://localhost:5000/ で確認 # デプロイ $ firebase deploy
感想
Firebaseの認証詰まったり、Cloud Functions 思ったよりハマりポイントたくさんありましたが一応SSRできるっていうのを試せてみたので良かったです。 サーバレスってこういうことなんだっていうのはやっぱり触ってみるとわかりやすいです。 もう少しルーティングとかうまくいくか検証しないと案件とかでは怖いですが
ほか参考
Shifter Headless をさわってみる
Shifter Headless とは
これまでのShifter = WPの静的書き出しは、「Shifter Static」と呼ばれ、今回新しくWP（REST API）をHeadlessCMSとして使うのを「Shifter Headless」と呼ぶようです。
前回のShifter（Static）の記事：https://jtk.hatenablog.com/entry/2019/11/24/124457
料金
データ転送
- 1000GB => $900/月
- 100GB => $72/月
- 10GB => $48/月
アカウント初回登録後1週間は無料プランあり
手順
会社の技術調査も兼ねて無料枠で使ってみました
Shifterへログインして「Headless」を選択後、サイト名を入力。
2〜3分でWordPressこみこみのサーバーが立ち上がりました。
WordPress管理画面は Shifter Dashboard に書いてある情報を入力。（ユーザー名は admin ）
最初は英語版ですが、いつものWordPress管理画面です。
WordPressの管理画面URLから /wp-admin/ を取ったURLでは Headless用のテーマが適用されています。
もちろんnoindexがはいっています。
プラグインも互換性があるものは最初から入っている。
けど、プラグインの新規追加はできない。
RESTだけでなくGraphQL配信もできそう。
ユーザーも作成可能。
サイトURL+ /wp-json/ を付与するとAPIができてることを確認
Shifter DashboardからWordPressサーバーをストップしても、WPやAPIのURLは変わりませんでした。
フロントエンドのスターターはGitHubにおいてあります https://github.com/smartcatdev/WordPress-REST-API-Sample-App
感想
プラグインの新規追加ができない点
これはデフォルトで入っているプラグインでしかWPの拡張ができないので、WordPressのコンテンツ管理周りでできることとしては下記が中心になるかなと思います。
- カスタム投稿タイプの作成（Custom Post Type UI）
- カスタムフィールド作成（Advanced Custom Fields）
- クラシックエディターの有効化（Classic Editor）
- テーブル入力まわりの強化（TablePress）
- 投稿順序の並び替え（Intuitive Custom Post Order）
- ページリダイレクト管理（Redirection）
- ユーザー権限のカスタマイズ（User Role Editor）
- コンテンツ移行（All-in-One WP Migration）
主要な機能は最低限カバーされている感がありますが、2つ懸念があります。
1.プラグインに依存していたサイトの移行が難しそう
旧サイトからの移行の場合、そちらで使用していたプラグインの機能は再現難しそう（Staticでも同じでしたが）なので、その点機能やコードの改修が出てくるかなと思います。
例えばWP-PageNaviの機能をフロントでやろうとすると結構大変な予感がしています。
小規模であまりテーマもいじってないですよーなサイトならやりやすそうです。
2.細かいところに手が届かない場合も
2つめはふだんのWordPress案件でよく使っているプラグインも使えないので、WordPress開発もできるしって理由が第一でこれを使うと大変なことにはなりそう。
functions.phpを触ることもできないので、ちょっとコード書いて管理画面の使い勝手よくするみたいなことも難しい。まぁフロントエンド向けなのでそうなのですが。
Headless CMSなので配信側で使うものという捉え方が必要で、残りはフロントでコネたりフォームはSaaS使うとかそういう選定はWordPress外でまた必要になる。
ちなみに自分がいつもいれるプラグインでないのは、
- Duplicate Post
- All in One SEO Pack
- Admin Menu Editor
あたりで、がっつり管理画面側の最適化だったので、わりとどうにかしやすい方だと思います。
セキュリティ面（WPのサーバー・APIアクセス）やサーバーの安定性が不透明
WAFをいれているってことなのですが、管理画面のIP制限ができなそうだったり、APIもURL叩けば表示されるので、そのあたり厳密な案件は難しいかもしれないです。
あとはmicroCMSとかも同じですがサーバどれだけ落ちる可能性があるのかとか、そのあたりも許容できる案件とか使い方になってくるかなと思いました。
まとめ
WordPress開発を多めにやってきた人間からすると、プラグインの使用限度がネックになってしまうなと思います。
ただWordPressサーバーの構築や管理もいらないし、そのあたりのやりたいことと手間暇との天秤かける感じになるかなと。
WordPressのCMSの管理画面って長い時間かけて5.xまで来ているので、そうそうに他のCMSで更新が完璧にしやすいのは出てこない気がしますし、そこもShifter Headless使う理由になりますね。
グーテンベルクに慣れている人はどれだけいるかわかりませんが、今まで触ったことがある母数も相当多いでしょうし
このような案件だと使うメリット多いと感じました。
参考リンク
【読書メモ】Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂3版
AWS含むクラウドでの個人的な苦手領域がネットワークとセキュリティ関連なのですが、その点をうまく補完できそうな本を読んでみようと思いました。
目次
- 1章 システム構築をインフラから始めるには
- 2章 ネットワークを構築する
- 3章 サーバーを構築する
- 4章 Webサーバーソフトをインストールする
- 5章 HTTPの動きを確認する
- 6章 プライベートサブネットを構築する
- 7章 NATを構築する
- 8章 DBを用いたブログシステムの構築
- 9章 TCP/IPによる通信の仕組みを理解する
実際の本番環境などではインフラエンジニアに任せるにしても、アプリケーション開発者もインフラ（ネットワークやサーバー）構築について理解があったほうがトラブルシューティングなどもしやすいしいいよね、みたいなスタンスで書かれています。
1章は概要説明で、2章からハンズオンで単一AZ構成のWordPressサイト（EC2のWebサーバー層 + DB層）を作っていきます。
Webサーバは一般的な方法と思いますが、DB層はプライベートサブネットにMariaDBインストールしてNAT経由でゲートウェイ設定する。
最後までインストールやってみて、動作確認して、請求怖いのですぐに環境削除しました。
良かった点
- 初心者向けでAWSサービス以前に、例えばIPアドレスとは？などそもそもの基本についての説明がある。
- AWSのサービスをベースにネットワークについての知識がつけることができる。
- ハンズオンを通して実際の構築を最小限の構成で通して学べる。
- 本のボリューム（価格含め）に対して、ハンズオン通してできあがる成果物の規模は小さめではあるものの、ハンズオンに沿った内容以外にも通例・慣習などの考え方についても説明があるので実戦をより想定しやすい。
まとめ・感想
自分はフロントエンドのエンジニアなのですが、所属する会社はメインの事業でクラウドのインフラ構築・運用をしていて、他の人が何やってんだろっていうのを今までの本の中では一番具体的に学べた（想像できた）本かなと思います。
サーバーにApache入れるとか（UdemyのSAA対策のハンズオンでもやりましたが）そもそものどうやって動いているの？っていう疑問が結構晴れました。
9章のTCP/IPなど通信の仕組み的なところはまだまだはてななところありますが、前に比べて随分用語の苦手意識がなくなっているように思えました。
SAPの試験対策も含めているのですが、もう少し包括的にAWSを知ってみたいとさらに思えるようになりました。やっぱり試験勉強よりはこういう感じで知識つけたほうが本質的には理解が進むような気がしました。
おまけ
次回も引き続き 定番業務システム14パターン 設計ガイド を買ったので読んでみたいと思います。パラパラ見てるだけだとSAP対策にもよさそう。
SAP試験の対策本 も今度出るみたいなのでそれも読んでみたいですね。（アソシエイト3資格対策のシリーズなので質がよいかわかりませんが..）