まじめに作らない技術

業務ではプロトタイプやら新規提案などでこれやりたい、あったらいいなという話は山ほどあるのですが、その中では本当に業務を改善するいいアイデアもあれば、とりあえず言ってみたけどその人がそう思っただけで他の人は全く不要だったみたいな話はよくあります。

そういういる/いらないを見極める技術は別途必要として、仮に何かしらのプロトタイプを作るにしても、なまじエンジニアとしてそこそこ経験があれば自分の得意な技術スタックで作りたくなってしまいます。

それはそれで問題ない場面もありますが、私はそれをやって以下の点を経験しました。

• プロトタイプといえど、自分の思ってたより、ユーザーが期待している期日よりも時間がかかる。
• プロトタイプで試してもらっている際の使用されたときの修正要望に想定以上に工数がかかる。その作業の多くがエンジニアでないと対応できず、業務チームに運用を引き継げない。

上記を踏まえ、事業として継続的に工数を投入できるのであればともかく、そうでなければなるべくまじめに作らず、出来合いのものでごまかすスタイルで反応を見ようとするようにしています。

そこでまじめに作らないパターンを書いてみました。

プログラミングをしない

そもそもコードを書かずにアイデアを実現できるのであればそれに越したことはありません。 世の中のノンプログラミングサービスを使って、さくっと作ってしまうという手があります。

代表的なノンプラグラミングサービスとしてkintoneが上げられます。 kintoneは簡単な案件管理やフォームみたいなものがつくれるので、要件さえあえば６０点ぐらいのモノはGUIのみで作れます。 プロトタイプとの相性は良いと思われます。ポイントは６０点で止めてそれ以上作らないことです。

kintoneの使い勝手については以前所感を書いたのですが以下のような感じです。

rso.hateblo.jp

また、モバイルのノンプログラミングサービスとしてはbubble などが挙げられます。

bubble.io

こちらは私はそこまで詳しくは知らないのですが、それっぽいモバイルアプリが作れるとのことです..

ノンプログラミングツールの最大の利点は、工数の短縮だけでなく、プログラムが書けない人に運用を引き継げるという点にあります。 プロトタイプが万一気に入ってもらえたら、一旦それをユーザに渡して試行錯誤してもらうという手法がとれます。

欠点としてはノンプログラミングツールでの表現能力には最終的に制限があるものがほとんどなので、作り込むにつれて辛くなってきます。 本格的に開発をするのであれば、プロトタイプを捨てて本開発に切り替えることを視野に入れる必要があります。

インフラを作らない

アプリケーションコードは自前で作るにせよ、それを動かすためのインフラを構築するのは予想以上に手間のかかる場合があります。 インフラ構築にかかる時間はユーザには見えないので、苦労の割にインパクトを与えることができません。

そのため、インフラの構築、運用はできるだけ省力化する必要があります。 インフラで真っ先に思いつくのはAWSかもしれませんが、AWSも慣れている人でなければそれなりに構築コストがかかり、それよりも おすすめなのが以下の３つです。

Heroku

PaaSとして アプリケーションコードをデプロイすればあとは勝手に動いてくれるので、インフラ層を気にする必要がありません。 また、Heroku Pipeline が絶妙に欲しい機能を提供してくれており、必要最小限の開発、ステージング、本番などのデプロイ環境をすぐに用意することができます。

Firebase

ウェブサービスがほしいものを全て盛り込んだサービス。認証、データストア、ファイルストレージ、ホスティングなど、一通り必要なものが提供されており、さくっと作れることに特化しています。

Netlify

静的サイトホスティングサービスで、PHPなどのサーバサイドは動かせませんが、フロントエンドの環境構築をこの上なく簡単に行ってくれるサービスです。 Githubと連携すればすぐにデプロイできるようになり、開発、ステージング、本番などの環境もすぐに作れます。 Nuxt.js などのSPAモードと相性が良いです。

世の中の素晴らしいライブラリを借りる

優秀なエンジニアは自分ではつくらず他からコードを借りてくるといいますが、自分がときたい問題に対して、既に世の中にある優秀なライブラリを適合させることができれば、 ずっと短時間で品質の良いものができます。問題は世の中のライブラリをいかに知るかですが、これは日頃の自分の道具箱をどれくらいもっているかによってしまいます。 ですが、最近はawesome-xxx という優秀なライブラリを集めたリポジトリがいくつかるので、そういうライブラリ集をストックしておくと良いかもしれません。例えば以下のようなものです。

• Ruby https://github.com/markets/awesome-ruby

• JS https://github.com/sorrycc/awesome-javascript

さらに上記のようなawesomeシリーズを集めたリポジトリまであります。

github.com

暇なときにこういうリポジトリを眺めていると新たな発見があるかもしれません。

ワイヤーフレームでごまかす

これはどちらかというと作らない方の選択なのですが、なんとなくの紙芝居などの画面イメージを作って合意を得るという方法です。 私の使ったお手軽紙芝居ツールとしては Prott が挙げられます。

prottapp.com

ただ、ワイヤーフレームで合意を得るのは個人的にあまり効率的ではないと考えます。開発初期のワイヤーフレームで認識があうのはごく一部の部分しかないからです。 細かい話は個人的な新規サービスアンチパターンとして書いてます。

rso.hateblo.jp

まとめ

とくにまとめませんが、滝のように流れてくるユーザの要望を受けながら考えていることを書いてみました。

読書メモ アプレンティスシップ・パターン

以前から持っていた本なのですが、久々に読み直したのでその内容をメモっておきます。 それほど世間一般で有名でない本かと思うのですが、個人的にエンジニアの心に刺さる名著です。

アプレンティスシップ・パターン　―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

概要

卓越したソフトウェア開発者になることを切望する駆け出しエンジニアに心構えを説く本。 中世の工房で働く徒弟制度に倣って、それらの弟子(アプレンティス)の日々己の技芸を磨いていた世界をモデルとして、 ソフトウェア開発で技術を磨きたいエンジニアに日々直面する課題と解決策をパターン形式で解説しています。

所感

この本では 駆け出しエンジニア向けの心構え指南本と書いていますが、結構抽象的な内容が多いため、駆け出しエンジニアには実はそれほど 実感が湧かないのでないかと思います。 しかし、ある程度ソフトウェア開発の現場で辛酸をなめ、苦労したエンジニアが読めば、ここに書いてある内容は心に刺さると思います。例えば、 技芸の習熟を志すが、年齢を重ねるにつれて、自分の思ったようなキャリア選択肢が見当たらない.. 現場があまりにも混乱している.. 管理職への昇進を命じられ、世間はそれを歓迎している.. ソフトウェア開発でない別の道の方が向いているような気がする.. などなど、ソフトウェア開発に従事している以上一度は体験するお悩みとそれに対してどのような行動が推奨されるのか、見事に記載されています。先人の筆者たちも同じく苦悩して、どう決断したが書かれています。

この本の良いところは、自分の漠然とした悩みを言語化し、パターン化してくれていることです。言語化されていることにより、 自分の悩みがエンジニアにとってある程度の普遍性を持つこと、そして言語化されていることによりこの内容を上司や同僚との会話することが可能になります。

非エンジニアのビジネスチームの人にもエンジニアの悩みとかこういうものだ、ということをかいつまんで説明するのにも使えます。 内容自体は抽象的な説明も多いので、自身や周りの人たちの現場経験にうまく適用して説明するのが良いかと思います。

冒頭でも書きましたが、それほど有名ではない(と思っている)し、あまり売っていない本ですが、 ソフトウェア開発に関する技術の向上を志し、将来に悩むエンジニアにはバチっとくる本ではないかと思います。

Auth0の管理画面から ユーザ検索する方法

Lucene syntaxに慣れていない方向け。 ぱっと検索したいときになかなか出なかったので、メモっておきます。

名前完全一致

name:"AAA"

名前部分一致(正規表現)

name:/AAA/

メールアドレス一致

email:"sample@auth0.com"

auth0id一致

user_id: "xxx|xxxxx"

詳しく知りたい方は

lucene syntax

https://lucene.apache.org/core/2_9_4/queryparsersyntax.html

読書メモ 入門 監視

掲題の本の読書メモを残しておきます。 最近はインフラ系の本のネタが多めです。普段JavaScriptばっかり見てる反動かもしれません。

入門 監視 ―モダンなモニタリングのためのデザインパターン

概要

監視に関する考え方とその方法論について広く解説しています。ざっくりまとめると、

• 昔ながらのオンプレミスのシステムでなく、クラウドで動作しているシステムに関して監視の考え方とその方法を解説
• ビジネスKPI, フロントエンド, サーバサイド, ネットワーク, セキュリティ のそれぞれで監視すべき内容と方法を説明。ただし、 個別のフレームワークや製品の使い方についてはほとんど立ち入らない。

といった感じでした。

所感

自分は監視と言うとメトリクス収集したり、エラーログ見つけてアラート投げるんでしょぐらいの理解でしたが、もっとビジネスKPI含めてシステムの何の振る舞いを監視すべきか、どう監視すべきかなど、 監視に関するそもそもの考え方から説明されており、非常に参考になります。

さらにフロントエンドやサーバサイド、ネットワークなどそれぞれの技術領域ごとの監視の基本戦略を解説しているので、 実務での監視の導入や見直しの前に見ておくと有用かと思います。

ちょっと余談ですが、ネットワークの部分だけやたら詳細な気がしたのですが、これは筆者がネットワーク好きなんだろうなと勝手に思いました.

また、副題にモダンなモニタリングと書かれていましたが、コンテナで動くシステムの解説はあまりなく、このあたりの監視方法ももう少しあればよかったなと思います。 個別のフレームワークや製品には立ち入ってないレベルでの説明なので、(あえて言うとLinux前提なのでWindowsユーザには少し微妙かもですが) 使用している製品に関わりなく役立つ内容かと思います。

AWS API GatewayのLambda Proxy Integration 使用時にLambdaのタイムアウトとその検知の扱い

掲題のやりかたについてちょっと調べたので、その内容をメモしておきます。

Lambda プロキシ統合とタイムアウト

API Gatewayから Lambda連携する際に、Lambda Proxy Integration(プロキシ統合)という機能を使用すると、 API GatewayからのLambda呼び出しと、そのリクエストとレスポンスをよろしくマッピングしてくれるので、いちいちマッピング定義を書かなくても LambdaとAPI Gatewayを連携できるのでよく使うのですが、Lambdaのタイムアウト(実行時間超過)の扱いについてちょっと困りました。

Lambda プロキシ統合を使用すると、統合レスポンスのマッピングが自動化されるので、個別に設定することができません。 さらに、LambdaがタイムアウトしたときのメッセージはLambda側でいじることができないので、API Gatewayからは 以下に説明されているような 502 不正な Lambda プロキシ応答 として認識されてしまい、 API Gateway呼び出し側からは非常に分かりづらい ものとなってしまいます。

aws.amazon.com

いろいろ試行錯誤しているうちに、以下のような方法で落ち着きました。

• API GatewayのLambda プロキシ統合使用時にLambdaのタイムアウトをハンドリングするのは諦めて、基本的に API Gatewayのタイムアウト時間 < Lambdaのタイムアウト時間 になるように設定する。
• 上記の設定により、Lambdaがタイムアウトする前に、API Gatewayが 504 Gateway Timeout を返してくれるので、それで分かるようになる。

タイムアウトの検知

次に、Lambda or API GatewayでのタイムアウトをCloudWatchに書かれるログを見ながら、指定した時間枠に一定数以上発生すればアラートを投げるという処理を考えます。タイムアウトをログから検知する方法は以下の２通りが考えられます。

• Lambdaのログから検知する。Lambdaのタイムアウトメッセージは変更できないので、 "Task timed out after xxx" という文字列を引っ掛けてCloudWatchで集計する
• API Gateway の ログから検知する。 API Gateway がタイムアウトした場合は、 以下のような 504 Gateway Timeout が記録されるので、このステータスと、resourcePath を使って、どこがタイムアウトしたかを検知する。

{
    "requestId": "xxxx",
    .... 
    "requestTime": "06/Feb/2020:10:32:29 +0000",
    "httpMethod": "GET",
    "resourcePath": "/test",
    "status": "504",
}

また、API GatewayのログをCloudWatchへ書き込むには以下の手順を行う必要があり、デフォルトでは出力されません。

aws.amazon.com

今回は後者のAPI Gatewayでのログ集計と検知を採用しました。理由としてはLambdaの変更できないメッセージを検索文字列として引っ掛けるのは気持ちが悪いのと、API GatewayとLambdaのタイムアウト時間は微妙に異なるので、Lambdaが応答返したけどAPI Gatewayはタイムアウトを返しているケースなどが拾えないなどがあるからです。

...と まあやってみると普通に至極当たり前のような内容を書いただけになっているかもしれませんが、一応調べてこういう内容になったということを記録として残しておきます。