読者です 読者をやめる 読者になる 読者になる

do:kalaclism

『輝かしい青春』なんてなかった人のノート

Windows Subsystem for Linux で 普通の Archlinux を使う

Development Knowledge

方法について書きます。


0. 参考にしたモノ

www.kunst1080.net

redd.it

1. 下準備

  • Windows Subsystem for Linux が使えるよう、その機能を有効にする
  • Bash on Ubuntu on Windows の初期設定を行う
  • Archlinux の Installer ISO ディスクイメージを用意する

2. WSL の Ubuntu を Archlinux Installer ISO のモノと入れ替える

2.1 Windows 側で AIROOTFS.SFS を取り出す

まず、 Archlinux の ISO をマウントして、

ARCH/X86_64/AIROOTFS.SFS

を、どこか適切なディレクトリにコピーします。

これは例えば、僕の場合だと、

C:\Users\nyarla\Downloads\AIROOTFS.SFS

にコピーしました。

2.2 WSL Ubuntu 上で AIROOTFS.SFS を展開する

次に、WSL Ubutnu の Bash に入り、

$ sudo su -

root になった上、

# cd ~/
# cp /mnt/c/Users/nyarla/Downloads/AIROOTFS.SFS ~/ # 先程の AIROOTFS.SFS を WSL 側にコピー
# apt-get install -y squashfs-tools                # squashfs を展開する為のツールをインストール
# unsquashfs ~/AIROOTFS.SFS                        # `AIROOTFS.SFS` を展開

という感じで、 AIROOTFS.SFS を WSL の root$HOME に展開します。

2.3 WSL Ubuntu を終了し、 Windows 側 で rootfs を入れ替える

そして最後。

先のステップで展開した、

%USERPROFILE%\AppData\Local\lxss\root\usquashfs-root

を、Explorer か何かで、

%USERPROFILE%\AppData\Local\lxss\rootfs

と入れ替えます。

2.4 Windows 側で WSL のデフォルトユーザーを root にする

これはコマンドプロンプト系の何かで、

lxrun /setdefaultuser root

と、すれば良いです。

3. Archlinux Installer で Archlinux の rootfs を構築する

これについては、手作業でその作業をすると大変につらい (というかつらかった) ので、 下記の様なスクリプトを使って作業します:

※ ただし、このスクリプトは無保証です。エラーとか有ったら各自直してください

3.1 Archlinux Installer で Archlinux の rootfs を bootstrap する

これは、上記のスクリプトを用意した上で、

# cd ~/
# ./wslarch-bootstrap.zsh bootstrap

するだけで OK です。

3.2 Archlinux の rootfs と Archlinux Installer の rootfs を入れ替える

これは WSL を終了した上で、 Windows 側から、

%USERPROFILE%\AppData\Local\lxss\root\rootfs_arch

と、

%USERPROFILE%\AppData\Local\lxss\rootfs

を入れ替えます。

3.3 Archlinux の rootfs を修正する

これは、先のステップで使用したスクリプトをもう一度使い、

# ./wslarch-bootstrap.zsh postinstall

すれば良いです。

以上

という事で、ここまでの作業を行えば、一応は、

(VM 等で)普通の Archlinux をインストールしたばかり

に近い環境が出来るはず、です。

ただし、WSL は Unix-like 環境における Wine みたいなモノなので、 時々、 Syscall の実装関係でソフトウェアが動かなかったり、 あるいは、この作業をしていた時にハマった罠の様に、

(ソフトウェアの) バージョンを上げたら、コマンドがぶっ壊れていたでござる

とか普通にあるので、まあ、本来なら動くはず……というところでソフトウェアが奇妙なエラーを吐いて止まったりしていたら、 WSL の、

github.com

とか見て周りましょう。そうしないと、僕の様に無駄に時間を消費して精神が消耗する、 みたいな事になります。


という事で、今回の記事は以上です。

何かの参考になれば幸いです。はい。

AWS Lambda + Amazon API Gateway の使い道

Development Knowledge Memo

僕個人としては、

  • AWS Lambda + Amazon API Gateway

という組合せは、現代に黄泉返った CGI みたいなモノだと認識しているのですが、 この AWS Lambda + Amazon API Gateway 、上手く使えば Web サービスの質を向上させたり、 あるいは、経費削減とかも可能になるのでないか (未検証) と思っています。

しかしながら、 AWS Lambda + Amazon API Gateway と言う組み合わせは、 ひとクセもふたクセも有る代物なので、今回はその辺りも含め、 ザックリと AWS Lambda + Amazon API Gateway の使い道について書いてみます。

※ ただし、僕の視点は、あくまで Web 開発者としてのモノです

1. この組合せで出来るコト・出来ないコト

基本的に、

  • AWS Lambda + Amazon API Gateway という組合せ

の、出来るコト出来ないコトは、それぞれのサービスの制約の集合になります。

これは例えば、

  • Amazon API Gateway は UTF-8 なレスポンスしか返せない
  • AWS Lambda は、特別なコトをしなげれば、特定の言語しか動かせない
  • AWS Lambda は、処理時間に制約が有る

という辺りなんですが、逆に言えば、これらの制約が問題と成らなければ、 基本的に何にでも利用できます。

2. Lambda + API Gateway の使い道

今の所、

  • AWS Lambda + API Gateway が向く使い道

として僕が思い付いている使い方は、

  1. Node.js (Lambda) での Server-Side Rendering Frontend としての利用
  2. ランタイムを問わず、Web hook の callback 先としての利用
  3. 簡易フォームなどの、VM の インスタンスを立てるまでもない処理

辺りです。

それで、2番と3番に関して言えば、これは CGI 代わりに使う、という感じのイメージですが、 1番についてもう少し説明と言うかアイディアの詳細を書くと、

  1. Lambda では Node.js v4 を Runtime とする
  2. API Gateway は Routing に用いる
  3. Lambda + API Gateway からの Backend の問合せには GraphQL 辺りを使う

という感じです。

そして、なぜ

  • Lambda (Node.js v4) + API Gateway を Server-Side rendering の Frontend

とするのが良いのかと言うと、理由としては、AWS にインフラを集約している場合、 Node.js での Server-Side Rendering を行うためだけに VM のインタンスを用意する必要がない 、 と言うのと、あとは、GraphQL などの、API 用の Interface を間に挟む事によって、 Backend 側の更新などが行いやすくなる、という辺りです。

まあ基本的には、

  • Frontend と Backend が疎結合となり、コスト削減にも繋がる

という辺りがメリットだ、と僕は思っています。

ただまあ、最近開発とか出来てない影響で、これについては未だに検証出来てないので、 実際のサービス運営でそれが通じるかどうか、については、未知数ですが。

まあでも、基本的には Lambda + API Gateway は、あんまりコストが掛らない、 という認識なので、まあ多少はなんとかなると思いますけども。

3. ただし、やり過ぎには注意

ただまあ、いくら Lambda + API Gateway がコストが抑えられて気楽に使えるから、 と言っても、それですべてを完結させる CGI-like な 環境として使うのは、ちょっとどうかなーって思っています。

と言うのも、特に僕にとっては、

  • AWS Lambda + Amazon API Gateway + 何かのデータストア

で完結させられるサービスを作るのは、楽だしコスト安いし、マネーを投下し続ければ無限にスケールするし、 で、良い事づくめな印象なんですが、いかんせん AWS に強く依存してしまうので、インフラを乗り換えにくくなる、 と考えられますし、また、AWS のインフラがなんらかの事情で止まってしまうと、そのサービスも無論死にます。

そのため、ミッションクリティカルと言うか、完全なサービス停止が要件上出来ないサービスに、 この組合せを用いるのは、ちょっと止めといた方が良いんじゃないかな、と僕は思います。

ただ、そうは言っても、ちょっとした Web Application で、Heroku とかでもオーバースペックな用途だと、

  • AWS Lambda + API Gateway を CGI-like に使う

と言うのは、結構良い選択肢なんじゃないかなー、と僕は思います。

と言う事で以上です

まあ、AWS Lambda + Amazon API Gateway という組合せは、簡単な Web Application を載せたり、 あるいは、フロントエンドサーバをコスト削減しつつ用意する、という用途にはかなり向くのでは? と僕は感じているので、もし案件等に合えば、使ってみるのも手じゃないかなーと思います。

Web を内容毎に自動分類する上での処理の流れ

Development Knowledge AI

概要

  • Web ページを内容毎に自動的に分類したい!

と考えた時に、

どの様にその処理を行なえば良いか

と言うのを今日調べてたので、一度考えを整理する意味でも書き出してみます。

Web を内容毎に自動分類する上での処理の流れ

基本的にはプログラミング言語を問わず、下記の様な流れになるっぽい:

  1. Web ページから本文を抽出する
  2. 抽出した本文を分かち書きをする (特に日本語の場合)
  3. 分かち書きをしたテキストを、ベクトルやスコアなどに変換する
  4. そのベクトルやスコアから、関連度を抽出する
  5. そして最後に、その関連度を利用して分類する

そして多分、どれも機械学習とかニューラルネットワークを絡ませる事は出来るんだろうけど、 まあ、その手のヤツは 3 番から絡ませた方が良いんでね? と個人的には思います。

以上

僕自身、機械学習についてまだ良く判ってないんで、あんまりこの内容も正確じゃないですが、 ま、多分こんな感じの流れになるんだろうな、と、今のところは思ってます。

なんか突っ込みとか有れば、コメント欄でよろしくお願いしますです。はい。