Rubellum fly light

ほぼPHP日記

HTTPリクエストを手順に送るだけの小さなワークフローエンジンを作って試行錯誤中

ライティングソフトウェアを読んで、サービス指向なアーキテクチャでクローラを作っています。

サービス指向なアーキテクチャの簡易図
サービス指向なアーキテクチャの簡易図

この中で〜Managerはワークフローエンジンによって処理を順に実行するだけのサービスとなっています。

処理自体は主に下位の〜Accessに対して手順通りにリクエストを投げるだけです。

このワークフローエンジンは自前実装でなく3rd Partyツールを使うのがライティングソフトウェア的には筋ですが、仕組み的に素朴なものがほしかったのでRubyで自前実装することにしました。

※コードは今のところ公開していません。

元々はGoogle Workflows、その後VM移動した都合でOSSのn8nを使っていました。

自前な素朴ワークフローエンジンは次のようなyamlを定義してリクエストを順に送ります。

miniflow:
  # ソースクロールキューを生成する
  - name: search-source_crawl_queue
    url: http://localhost:8080/v1/source/search
    params:
      condition:
        type: rss
        schedule_with:
          type: hourly
        limit: 100
      format:
        type: crawl_job
        opts:
          skip_enqueue_if_exists_entry: false
    result: crawl_job_get_result

  # ソースクロールキューを追加する
  - name: crawl_job-add
    url: http://localhost:8080/v1/crawl_job/add
    params:
      crawl_jobs: ${result.crawl_job_get_result.result.items}

${〜}で変数を埋め込めるようにして、前の実行結果を引き継げるようにしました。

リクエストの方法は今のところPOSTのみでHTTPリクエストのBODYにJSONを記述して送るだけの仕組みになっていますが、 このあたりはパラメータでいくらでも拡張できるので必要になったら作ればいいと考えています。

APIをうまく設計すればHTTPリクエストを順に送るだけで柔軟に機能を実現できます。

まだ、サービスが4個、APIが2〜30本くらいの規模感のソフトウェアしか作っていませんが、設計の感触はなかなかいいです。

お試し GitOps

GitOps を試すために Kubernetes のクラスタと ArgoCD をVPS(VM4台)に構築し、自前サイトをのっけてみた。 そもそも k8s を触ったことなかったので、AWSやGCPのマネジメントクラスタを利用せず、自前で小さいクラスタを構築した。

ひとまず GitOps できる環境構築までは完了。 git リポジトリにプッシュすると k8s クラスタにデプロイできるようになった。 git リポジトリの中身はまだ素のnginx+HTMLファイルみたいな静的サイトなので、次はPHPアプリケーションあたりを試したい。

git リポジトリは GitLab.com (Saas) を利用。Private Container Registry が無料で使えたので。 GitLab.com は yaml をgitに入れておくだけで、プッシュのタイミングでイメージをビルドしてくれて神だった。 kojole.hatenablog.com はじめ registry への認証ができず、どうやら2段階認証がONになっていると docker login が通らないっぽかったのでOFFにした。 ちゃんと認証する方法はありそうなもののサボった。

type: LoadBalancer をこの環境でも使えるように MetaLB(L2), Nginx Ingress Controller を追加でセットアップした。なお type: LoadBalancer が何者かはよくわかっていない。

Nginx Ingress Controller のインストールはかなり詰まって、ここが一番大変だった。 最初はずっとエラーが出て解決しなかったので NodePort でお茶を濁していたものの、マニュアルの Bare-Metal の手順でなく helm でインストールしたらうまく行った。なんでだろう。

エラー内容を保存し忘れたが、たしかこんな感じのやつ(github issueから引っ張ってきた)。

Error from server (InternalError): error when creating "〜": Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": Post https://ingress-nginx-controller-admission.ingress-nginx.svc:443/extensions/v1beta1/ingresses?timeout=30s: context deadline exceeded

↓の手順を見て、 helm インストールした。Install nginx-ingress controller with Helm の見出しの部分(upgradeとなっているが初回だったのでinstallで実行) www.brightbox.com

外部IPをセットしていないので、今は k8s クラスタの前段に素の nginx をリバースプロキシとして置いている。

Kubernets が内部で何をやっているかまったくわからないのがかなり印象的だった。 これをオンプレで管理するの、なかなか難しそう。

PHPで雑にカラーコードを生成する

適当な文字列のmd5ハッシュから6文字だけ切り出し、頭に#をつけることで雑にカラーコードを生成できる。

PHPでの例。

<?php

$s = 'OK';
echo '#' . substr(md5($s), 0, 6);

大量のデータを表示するときに、グルーピングしたい単位(IDや日時など)でカラーコードを生成するとパッと見でわかりやすくなる。

Android アプリ開発をはじめた

Androidアプリ開発をはじめた。
ひとまずニュースアプリみたいなやつをつくっている。


Android Studio

普段 IntelliJ IDEA を使っているので、Xcodeより使い勝手に慣れててスムーズに開発に着手できてる。

ライブラリ

OSSのライブラリが大量にあるので、PHPとかRubyの人でも簡単に開発できるんじゃなかろうか。
ライブラリのインストールはgradleにパッケージ名書くだけでいいので楽だし、開発環境も無料だし。

Squareの圧倒的存在感を知る。
retrofit / okhttp / picasso etc...

デザイン

XMLでデザインを作っていくのどうなのと思っていたけど、GUIでポチポチやるより早い。
レイアウトの作り方に慣れると、途端に自由になれる。

Kotlin

Javaのコードをコピペすると、自動でKotlinに変換してくれるのちょっと感動。
モダンなプログラミング言語なので、書いてて楽しい。

画面づくりがメインだったので、ロジックはほぼ未着手でこれから。
APIと連携すると、ビューどスレッドがうんぬんで大変と聞いているので、山はまだ先らしい。

ボーン・コレクター/コフィン・ダンサーを読んだ

「ボーン・コレクター」は映画にもなっていて、地上波でも放映されていて、子供のころに何度かみた記憶がある。
アンジェリーナ・ジョリーと黒人のおじさん(いま調べたらデンゼル・ワシントンという俳優らしい)が出ていて、寝たきりのおじさんが探偵役っぽいことをしていたのをうっすらと覚えているくらいだったが。

原作小説の著者はジェフリー・ディーヴァーという人で、どこかのブログで「ジェフリー・ディーヴァー作品はどれから読むべきか」というのがとりあげられており、そのときあがっていたのが「ボーン・コレクター」だった。
(このときはじめて映画に原作があったことを知った)

Amazonで著者検索してみると、本屋で表紙を見たことがある作品がちらほらあって、「青い虚空」は学生のときに読んでいた。
そういえば、一時期”ハッカー”小説にはまりそうな時期があったのをふと思い出した。懐かしい。
「ボーン・コレクター」が「リンカーン・ライム」シリーズの1作目というのもこのとき知った(リンカーン・ライムはメインキャラ名)。

シリーズものは常に一作品目からたどって読むべき!という信条を持っているので、すでに映画を見たことがあるものの、一作目の「ボーン・コレクター」から読むことに。

「天才のリンカーン・ライム(と仲間たち) VS 天才の犯罪者」と、とにかく対決ものっぽい。
鑑識技術を駆使して証拠物件から犯人を追うリンカーン・ライムと警察(リンカーン・ライムは警察でなくコンサル(?)的な立場)、警察の行動を読み、裏をかいて自分の犯罪を実行していく犯罪者。
いまは2作目は「コフィン・ダンサー」を読み終わったところなので、すべての作品がこう進むかはわからないが。。

いま3作目以降の作品をまとめて注文して届くのを待っている。
リンカーン・ライムシリーズから派生した、キャサリン・ダンスシリーズも気になるところ。

データ構造を着飾るアプリケーション

最近、文章を書いてないのでリハビリがてら。

Google の"検索"

Google 検索のすごいところは、「検索」でなく「ソート」なのだとどこかで見た。
検索結果を"どのような順"で表示するかが、むしろ重要なのだと。

例えば、検索キーワードがページ内に多く含まれているWebサイトが検索結果のより上位に表示される、と考えてみる。
そうすれば、望まない検索結果が出てくるのは明らかだと直感的にわかるはずである。

つまり、Google 検索は、検索結果をユーザーが望む(であろう)順番にソートしている、といえる。

何を当たり前なことをと思うかもしれないが、
そのときは「検索」と「ソート」で受ける印象がだいぶ違う!と感じたのである。(アハ体験1)

Excel の"表"とTrelloの”リストのリスト”

話は変わるが、ジョエルオンソフトウェアで有名なジョエル先生が、Trelloについてのエントリを書いている。

matope.hatenablog.com

ここにExcelが広まった理由について考察が書かれている。

Excelを実際に「計算」と呼べるもののために使っている人間はどこにもいなかった。

ほとんどの人々がExcelをリストを作るために使ってたということだ。突如として私たちは、Excelを時代遅れにせんとした、上等な未来的スプレッドシートであるLotus Improvがなぜ完全に失敗したのかを完全に理解した。あれは計算が大得意だったが、表の作成はひどく下手で、そしてみんなはExcelを計算ではなく表のために使っていたからだ。

大部分のExcelユーザーが”表計算”でなく、ただの"表作成"に使っているのだという。
自分も思い返してみると、確かにただのそのような使い方をしていることが多いように思える。

どれだけ優秀な表計算シートも、表作成ソフトにはかなわなかったのである。
表計算のユーザーは少なく、表作成のユーザーは多かった。

ところでジョエル先生はこのエントリの中で、

素晴らしい水平的キラーアプリケーションとは、実際には着飾ったデータ構造に過ぎないのだ。

とおっしゃっている。つまり、Excelは”表”というデータ構造を着飾ってたアプリケーションなのだと。
そして、Trelloは「リストのリスト」を着飾っている。(アハ体験2)

表やリスト(またはリストのリスト)といったデータ構造は、多くの人が業務等で普通に使っているものである。
必然的にそれらの”データ構造”が(おそらく無意識的にだが)必要とされる機会も多くなる。

したがって、それらを着飾ったアプリケーションは広く使われる資質を持っているのである。
(もちろん多くの人に実際に使ってもらうのは大変だと思うけど。)

先程のGoogle 検索の例に戻って考えてみると、
Google 検索はソートというアルゴリズムを着飾っているといえる。

「データ構造とアルゴリズム」を着飾ったアプリケーション(Webサービス)

多くの人に使われるWebサービスを作りたいならば、
データ構造やアルゴリズムといった観点からサービスをみてみると何かヒントを得られるかもしれない。