Shifter Headless をさわってみる

f:id:jotaki:20191122165357p:plain

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こみこみのサーバーが立ち上がりました。 f:id:jotaki:20200610133317p:plain

WordPress管理画面は Shifter Dashboard に書いてある情報を入力。(ユーザー名は admin
最初は英語版ですが、いつものWordPress管理画面です。 f:id:jotaki:20200610133334p:plain

WordPressの管理画面URLから /wp-admin/ を取ったURLでは Headless用のテーマが適用されています。
もちろんnoindexがはいっています。 f:id:jotaki:20200610133326p:plain

プラグインも互換性があるものは最初から入っている。
けど、プラグインの新規追加はできない。 f:id:jotaki:20200610133342p:plain

RESTだけでなくGraphQL配信もできそう。 f:id:jotaki:20200610133348p:plain

ユーザーも作成可能。 f:id:jotaki:20200610133353p:plain

サイトURL+ /wp-json/ を付与するとAPIができてることを確認 f:id:jotaki:20200610133400p:plain

Shifter DashboardからWordPressサーバーをストップしても、WPやAPIのURLは変わりませんでした。 f:id:jotaki:20200610133404p:plain

フロントエンドのスターターは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サーバーの構築や管理もいらないし、そのあたりのやりたいことと手間暇との天秤かける感じになるかなと。

WordPressCMSの管理画面って長い時間かけて5.xまで来ているので、そうそうに他のCMSで更新が完璧にしやすいのは出てこない気がしますし、そこもShifter Headless使う理由になりますね。
グーテンベルクに慣れている人はどれだけいるかわかりませんが、今まで触ったことがある母数も相当多いでしょうし

  • 機能要件固まっていて、WPでめちゃめちゃ難しいことしない
  • セキュリティ要件もそこまで厳しくない
  • 更新する人がWordPress管理画面に慣れている
  • 開発側もモダンにやりたい(NuxtやGatsby

このような案件だと使うメリット多いと感じました。

参考リンク

【読書メモ】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資格対策のシリーズなので質がよいかわかりませんが..)

2020年5月 振り返り

結果

ブログ

目標:月 8 回(週2回)更新
結果:月 2 回 更新

読書

目標:月 1 冊
結果:月 1 冊

反省点など

この歳になって料理作るとか掃除するとか生活をしっかりしはじめてしまって、なかなかスキルアップに気が回りません。
2月までの勢いが自分のペースでは異常だったのですが、どこかで切り替えしないとなあと感じています。

来月に向けて

引っ越しなど色々終わらせてすっきりした状態になっていればいいなと思います。

【読書メモ】みんなのAWS 〜AWSの基本を最新アーキテクチャでまるごと理解!

ゴールデンウィークだけど外出もできないのでだらだら1冊だけ読みました。

目次

  • 第1章 AWSの基礎知識
  • 第2章 AWSで作るWebサービス
  • 第3章 サーバーレスプラットフォームで作る モバイル向けアプリケーション
  • 第4章 AWSで作るデータの収集・可視化基盤

ざっくりですが、第1章はAWSというよりクラウド(インフラ)の歴史から責任共有モデル、Well-Architectedフレームワークについて、IAMのアカウント管理やCloudWatchのモニタリングに関して触れています。
第2章でネットワーク、コンテナ、CI/CD環境...といったカテゴリー別にAWSサービスの紹介。
第3、4章でサーバーレスアプリ、データ収集基盤を実際に構築するハンズオン形式の解説となっています。

良かった点

ポイント・概要的なことはまとめるとキリないので良かった点だけ。

実際の構築に近い視点でAWSサービスを理解できる

これまで認定試験のAWS勉強だけだったので表層的な知識習得だったと思うのですが、この本では

  • どのような考えでアーキテクチャを設計するのか
  • 運用やセキュリティ目線ではどのようなことを考える必要があるのか

等、実際の案件に近そうな感じでシミュレーションができ理解が深まったように思います。

たぶん、他のAWS本でも同じ方向性の内容だとは思うのですが、特に良かったのはタイトルに「みんなの」って書いている通り、初学者の人にとっても学びやすい内容だったことです。
例えば、第2章でコンテナの説明を扱っていますが、ECRやECS、EKSの説明の前にそもそもコンテナとはなにか、向いているケースはどのようなケースかみたいな話が丁寧に説明されています。
解説されていることのほとんどは何となくは知っていたけれど、背景的な話や実際の構築に近い話が出てくるのでこれまでの本とは違う観点でAWSやそのサービスを見れるようになったかなと思います。

コンソールのキャプチャが多い

3、4章のハンズオンの中でキャプチャ多用されているので、実際にいじってなくても本の中だけで完結できるのはよかったです。寝る前とかに読めるので。

情報が新しい

試験本は若干古い情報が載ってたりするのですがこの本は新しいので、この比較表は内容古そうだからググって調べなきゃな的なバイアス抜けれるだけでだいぶ読むの楽だった感じがします。特にS3のストレージクラスなど。

まとめ・感想

もっとAWSのこと試験対策だけじゃなくで理解しようというふうに思いました。
1年ほど前からプラクティショナーの勉強始めて、そう思えるまでに時間かかってしまいましたが他の本なども読んでみたいと思います。

2020年4月 振り返り

結果

ブログ

目標:月 8 回(週2回)更新
結果:月 2 回 更新

読書

目標:月 1 冊
結果:月 2 冊

反省点など

なんででしょう。あれだけ欲しいと思っていた時間がすぐそこにたくさんできたはずですが、インプットもアウトプットもペースが落ちてしまっています。

来月に向けて

長い目でみてもう少し状況に慣れて、あまり無理せずやっていきたいと思います。

【読書メモ】他者と働く──「わかりあえなさ」から始める組織論

技術本ではないですが気になっていてほしいものリストにずっと入れてた本。
前回 読んだチーム・ジャーニーでハンガーフライトの解説で、対話に関して詳しく理解したい人におすすめの本として挙げられていたので、次に読んでみようと思っていました。

目次

  • はじめに 正しい知識はなぜ実践できないのか
  • 第1章 組織の厄介な問題は「合理的」に起きている
  • 第2章 ナラティヴの溝を渡るための4つのプロセス
  • 第3章 実践1.総論賛成・各論反対の溝に挑む
  • 第4章 実践2.正論の届かない溝に挑む
  • 第5章 実践3.権力が生み出す溝に挑む
  • 第6章 対話を阻む5つの罠
  • 第7章 ナラティヴの限界の先にあるもの

2章までが枠組みや、本で扱う問題や解決方法について、3章以降は事例を元に解説されています。

概要・ポイント

対話

知識として正しいこと、でも実践でもそれが正しいとは限らない。その問題を解決するために行うのが対話。
本の中での定義としては「新しい関係性を構築すること」
そもそもそのような問題が起こる要因、解決法としての対話のステップと方法はこうですよという話がこの本の大

技術的問題

既存の方法で解決できる問題

適応課題

既存の方法で一方的に解決ができない複雑で困難な問題
他の部署に協力を求めることが必要な課題を例とした関係性の中で生じる問題

関係性の改善

「私とそれ」という道具的な関係から「私とあなた」という固有の関係へシフトする。
自分の中に相手を見出すこと、相手の中に自分を見出すことが対話の意味である。

適応課題のタイプ

  • ギャップ型 価値観と実際の行動にギャップが生じるケース
  • 対立型 互いのコミットが対立するケース
  • 抑圧型 言いにくいことを言わないケース
  • 回避型 痛みを伴う行動に向き合わないケース

ナラティブ

物語、つまりその語りを生み出す「解釈の枠組み」のこと。それぞれ人がみんなもつもの。
ビジネス上では「専門性」「職業倫理」「組織文化」などに基づいた解釈が一般的。その人にとっての一般常識。
ナラティブ・アプローチとは、「どう相手に話をするか」よりも「どう相手を捉える私の物語を対話に向けていくか」を主軸にしたもの。

解釈

相手のナラティブにおいても意味があるようにするにはどうしたらよいのかを考えること
できれば信頼のおける仲間や相棒と一緒にやるのが望ましい

対話のプロセス

  • 準備 「溝に気づく」
    • 自分から見える景色を疑う
    • あたりを見回す
    • 溝があることに気づく
  • 観察 「溝の向こうを眺める」
    • 相手との溝に向き合う
    • 対岸の相手の振る舞いをよく見る
    • 相手を取り巻く対岸の状況をよく見る
  • 解釈 「溝を渡り橋を設計する」
    • 溝を越え、対岸に渡る
    • 対岸からこちらの岸をよく見る
    • 橋を架けるポイントを探して設計する
  • 介入 「溝に橋を架ける」
    • 橋を架ける
    • 橋を往復して検証する
    • 橋を補強したり、新しい橋を架ける

「準備」段階は歯がゆく勇気がいる。一度自分のナラティブを脇においてみることが大事。

対話の罠

  1. 気づくと迎合になっている
  2. 相手への押しつけになっている
  3. 相手と馴れ合いになる
  4. 他の集団から孤立する
  5. 結果が出ずに徒労感に支配される

読みながら1.は自分もそうなりそうだよなと感じていたが、迎合(忖度)は相手へ隷属すること、自ら気づいた課題意識や問題点を見ないようにすること、すなわち、諦めることを意味しているので、そこが対話との違い。(プロセスでいえば橋を渡ったまま帰ってこないのといっしょ)

あとは最後の辞めたり、休んだりすることも重要というのは大事な気がしました。

良かった点

  • 最後エモかった
  • インテル、レッドハットなどIT企業の例が多い

惜しかった点

  • 特になし

まとめ・感想

大学のときにメディア学すこしかじってて、ナラティブとか物語性(人は物語をつけたがる・求める)みたいな話に通ずるところがあり、今になってこういうテーマを見ることになるとはなあという感じでした。
例えば第3章の新規部門と既存部門の話など結構いまの仕事というか会社内でも関連する話がありました。
去年結構売れている本のようなのですが、こういう類の本が売れる(みんなが関心を持つ)っていうのはいいなあと思いました。

【読書メモ】チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

市谷聡啓さんの上記2冊に続いて、チーム・ジャーニーを読みました。
カイゼン・ジャーニーの続編ぽい感じだったので(実際には単体でも読める)2月の発売から楽しみにしており、3月に内容も多めだったのですが、ちょっとだらだらしながらになってしまいましたが読みました。

目次

第1部 僕らが開発チームになるまで─1チームのジャーニー

  • 単一チーム 基本編
  • 単一チーム 応用編

第2部 僕らがプロダクトチームになるまで─複数チームによるジャーニー

  • 複数チーム 基本編
  • 複数チーム 応用編

カイゼン・ジャーニーは、1人から始められるカイゼンを繰り返しチームが遷移していく(だけど焦点は個人に合っている)物語でした。
対してチーム・ジャーニーは、チームマネジメントやチームづくりについて、よりチーム全体に焦点を当てた内容になっています。
物語方式にて、まず問題(ストーリー・問題編)、次に課題(ストーリー・解決編)、最後に解説が各章にておかれています。
基本編で4章、応用編で4章、それが1部+2部なので全16章というボリュームになっています。

概要・ポイント

大枠として、度々書かれていたこと

  • なめらかに進める
  • 解像度を意識する
  • 状況によってフォーメーションを組む

チームマネジメントにおいて、一気に状況を変えようと思っても無理は利かないので段階的に予定を立て進めていく。
人によってその情報や状況に対する捉え方(視座=高低/視野=広狭)が違うので念頭におく。
ひとつの固定の役割、既存の概念に囚われず状況に応じて柔軟に配置転換、役割の創出などを行なう。

その他、気になったこと、なるほどと思ったことなど。

コンウェイの法則

プロダクトやシステム設計が、組織構造(チーム分割等)を反映したものになることをいう。
逆にプロダクトの機能などから組織構造を作ることを逆コンウェイの法則という。

取引コスト

もとは経済学の言葉で、違う文脈を持っている相手に対してコミュニケーション取ることは取引コストが高い、などという。

「リード」という役割

「リーダー」とは別の「リード」という役割
・リーダー => 組織上の職位として定義
・リード => ある状況において前進を先導する「役割」。例)テクニカルリード、仮説検証リード、テストリード

情報の解像度

レイヤーによって粒度分けて展開するのが望ましい。
例えばPOなどのレイヤーで細かな機能についてまで話を展開してしまうと、開発者メンバー側では情報を受け取って「ただそれを実装する人」になってしまう。
ある程度は余白もたせて PO => リード => 開発者 などに受け渡ししていき細部を詰める流れがよい。

番頭の輪番化

担当をローテーションすることで、トラックナンバー1問題(誰々しかこのコードを触れない問題)につながらないようにすること。

ただし、チームメンバーの専門性や関心などで、あるメンバーに依存する領域が生まれてしまうこと自体は悪いことではありません。むしろメンバーの多様性がいきている状態ともいえます。属人性を排除することを過度に目指すのではなく、何かが起きたときに他の人でプランB(本人ほど最適ではないが、他の人でもなんとか対応できる作戦)が立てられるかどうかを明らかにしましょう。

事前に許可を求めるより、後でゆるしを得たほうがたやすい

先に動いてしまって後でゆるしを得にいくということ
これ結構メンバー側目線で自分も意識していて、ケースバイケースではあるものの決裁権持っているひとにいちいち確認しても時間もったいない(=ボトルネックになる)と判断したら答え確定して出した方がいいなと

視座と視野で決まる視点

物事をどこからどこまでを見るようにするか、「どこから」というのは「視座」、「どこまで」とは「視野」にあたる。
その上で
・視座や視野への偏りをつくらないこと
・視座の高低と視野の広狭を自分たちの意思で行き来できること
が重要。

良かった点

  • 少し登場人物の名前が分かりづらいが、相変わらずストーリーがおもしろい。
  • 問題:課題:解説の割合、1:1:1 くらいですが、ある問題に対して内容割いている本も少ないように思うのでためになる。

惜しかった点

  • 特になし

まとめ

本に解説してある内容でも実際の現場では状況も違うので、その都度ベストな選択や考えを結局自分自身がしたり持ったりしなくてはいけないのだけれど、その幅が広がったり選択がしやすくなるような内容の本だと思う。

いっぽうで結局正解はないので読者の主観に後は委ねられる部分も多くある、そういう不確定要素を好まないひとには向いていないかもしれないが、筆者の「正しいものを正しくつくる」でさんざん語られていたように今の時代そういう開発形態も考えも主流になっていくなかでうまく自分も適用できるようにならないとと感じた。

最近発売されたオライリーみんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた の説明にも

本書では、「顧客から始める」「早期から頻繁にコラボレーションする」「不確実性を計画する」をアジャイルの3つの原則とし、...

と書かれています。
自分も今の会社に入って分かったのですが、結構クライアント側の方が開発に入ってくることが多く、その良い面みたいなのはすごく感じています。それでいて知識も豊富だと後ででてくる要件も出づらいのでやりやすいなと。

今回の本はチームビルディング的な観点だったので、いちメンバーである自分には適用しづらい内容も多かったですが、そういう視点も持ちながら働く/働かないではわりと違うんでは、と思っているのでもちょっと視野広げてやっていきたいと感じられました。