Apple Music – Taylor vs. Treadmill
⇧ Apple MusicのCMのテイラー・スウィフトが芸人顔負けの体当たり芸してますけど、スタントとか無しでやってるのかな？
テイラー・スウィフト（Taylor Swift、1989年12月13日 - ）は、アメリカ合衆国のカントリーシンガーソングライター、音楽プロデューサー、篤志家。女優として映画やテレビドラマにも出演している。グラミー賞10回受賞(32回ノミネート)、最優秀アルバム賞を史上最年少（20歳と49日）で獲得した人物。
立て続けにヒット曲を生み出しており、ファン層も広く、しばしば「America's sweetheart」と呼ばれる。
⇧ アメリカの人だったんすね、何か勝手にイギリスの人ってイメージがあったんだけど（エド・シーランと友達って情報に惑わされてたかも）、生粋のアメリカンなんすね、失礼いたしました。身長も178cmあるんですよね～。
「テルマ＆ルイーズ（監督：リドリー・スコット）」に出演してたジーナ・デイヴィスも183cm あったとか、流石はステロイド大国合衆国！アメリカはデカいな～。
どうも、ボクです。
そして、SWIFTと言えば、
国際銀行間通信協会（こくさいぎんこうかんつうしんきょうかい、英語: Society for Worldwide Interbank Financial Telecommunication）略称: SWIFT（スイフト、スウィフト）とは、金融機関同士のあらゆる通信にクラウドサービスを提供する非上場の株式会社である。本部はベルギーのラ・ユルプに設置されている。株主となる金融機関は各国に存在するため、同協会の事務所は各国に置かれている。
あらゆる国際決済が、スイフトを通じて行われている。証券決済における主要なトラフィックは、ユーロクリア、クリアストリーム、そして南アフリカJSEのストレートによる。1999年の同協会による発表では、日額約20兆フランス・フランを移転したという。
2016年2月現在、ブロックチェーンの共同開発に参加している。
⇧ ってなっており、
スイフトは、そもそもカストディアンを繋ぐ情報処理設備であった。
スイフトは、一貫して金融系の通信フォーマットの共通化、データ処理システムの共有、世界的ネットワークの設立を目指している。2007年10月、金融メッセージの規格に証券保管振替機構がISO 20022 を採用するよう確約させた。全国銀行データ通信システムとは、メッセージに互換性がない。2008年、NTTデータがメッセージを変換するサービスを開発した。
⇧ NTTデータが、 頑張ってたらしい！
日本では、資金決済でスイフトを利用する機会が比較的少なかったが、外国人労働者の母国への送金や、資金決済に関する法律の施行により、需要の増える可能性がある。
「swift」は、英語で「速い」「即座の」や「速やかに」などを意味する。金融機関同士の通信は従来テレックスや電報によって行われていたが、スイフトは通信速度を飛躍させた。また、その内容や通信文は確実に暗号化されたものとなっている。しかも、ネットワークに接続するコンピュータやインテリジェント端末装置はハードウエア、ソフトウエアとも協会が認定したものでなければならず、それらを製造する業者は世界中でIBMなど僅か数社しか認定されていない。
毎年秋に、ユーザーを対象とした会合Sibos を開催している。参加者は、資金/証券決済関係の銀行役員が中心である。
⇧ 「swift」の意味は、「速い」ってことが分かりましたね～。
OpenStackは、IaaSを構築するためのクラウド基盤ソフトウェアで、OpenStackプロジェクトによって提供されています。
2012年4月5日にリリースされた「OpenStack 2012.1」(コード名：Essex)は、機能・用途別に大きく以下の5つのコンポーネントから構成されています。
OpenStack: 分散オブジェクトストレージ Swift 第1回: Swiftの概要と構造 | 技術文書 | 技術情報 | VA Linux Systems Japan株式会社
⇧ 「swift」という言葉は、OpenStack ってクラウド基盤のソフトウェアでも使われていると...
どのSwiftの話をしてるのか訳分からんくなりそうなんだけど...
いろんな、「Swift」が出てきたところではありますが、
そんなわけで、今回は、Macでしか使えないとされていたSwiftについて、
Appleは米国時間3月21日、「Swift 2.2」をリリースした。同社が2015年12月に、「iOS」および「OS X」向けアプリケーション開発言語である「Swift」をオープンソース化した際に、「AppleはSwiftのオープンソース化にどれだけ真剣なのだろうか」という疑問が頭をもたげていた。
この疑問に対する答えは「かなり真剣だ」ということが明らかになった。同社は2月にSwiftのベンチマークスイートをオープンソース化したことに続き、今回のリリースからLinuxをサポートするようになったためだ。
⇧ 2016年3月21日に、Linux対応してたらしい。
具体的に述べると、サポートされるのは「Ubuntu Linux 14.04」と「Ubuntu Linux 15.10」だ。Appleは「Linuxへの移植はまだ初期段階であるため、今回のリリースには『Swift Core Libraries』（『Swift 3』で搭載予定）は含まれていない。しかし、デバッガ（LLDB：Low Level Debugger）と対話型評価環境（REPL：Read Eval Print Loop）は含まれている」という。
⇧ ディストリビューションとしては、Ubuntu のみの対応みたいですと。
そういえば、PHP Conference 2019 に行ってきました～。
⇧ 京浜蒲田駅～、場所が自分の最寄り駅からだと、ちょっと遠かったけども。
PHP Conference 2019 の前日の、
⇧ 冬のJavaScript祭で、お話してくださった方も、PHP Conference 2019に出席されてました～、自分ももっともっと勉強せねばって気持ちになりました、最近モチベーションがダダ下がり中ですけどね...反省。
ちなみに、冬のJavaScript祭りでは、『簡単にオフライン対応しよう（竹内 佑介【株式会社オープンストリーム】）』のセッションで知った、「Workbox」が「ServicWorker」の導入の敷居を下げてくれそうということで、チャレンジしてみたいと感じました。
んで、PHP Conference 2019ですが、個人的には、hnw さんの話が面白かったです。
⇧ PHPってインタプリタ言語っていう認識なんだけど、内部的にはコンパイルしてて、オペコードっていう中間コードが生成されるという。あと、PHPの例外処理の謎を追って、C言語のソースコードを読んで見つかった発見が衝撃でした。
あと、記事を書くために調査に時間がかかってたんで、
・https://www.seccon.jp/2019/akihabara/
⇧ 上記のイベントにも、参加して参りました～。
「GDG Tokyo | DevFest Tokyo 2019」では、『ネイティブアプリとWebアプリの差を埋めるには：Project Fuguとマルチスレッドプログラミング（清水 智公）』のセッションで、WebWorkerってのを使いやすくしてくれる、「Comlink」っていう存在を知りました。
ServiceWorkerは、WebWorkerの1種らしいとのことなので、ServiceWorkerでも使えるのかな？そうなった場合、「WorkBox」「Comlink」の違いってどうなるんだろう？
時間あるときに調べてみたいけど、「Comlink」については、
Comlink makes WebWorkers enjoyable. Comlink is a tiny library (1.1kB), that removes the mental barrier of thinking about postMessage and hides the fact that you are working with workers.
GitHub - GoogleChromeLabs/comlink: Comlink makes WebWorkers enjoyable.
⇧ てな具合ですと。
・https://www.seccon.jp/2019/akihabara/
んで、SECCOM 2019 では、セキュリティの啓蒙の難しさを感じましたかね。
そして、開発者がよく参考にするstackoverflowのソースコードに脆弱性があるらしい...それをコピペして使うから問題が起こると。ただ、APIとかの公式ドキュメントなんかにはソースコードのexampleが少ない、っていう調査結果が出たそうな...
もう、どうしたら良いのかね...
っていうか、公式のドキュメントは情報が少ない気が、って個人的には思ってたんだけど、事実少なかったんですね。（開発者は使える工数が限られているから、せめてドキュメントを充実させて欲しいですね。）
あと、ゲームエンジンのUnityで、LLVMが使われ出したらしいっす。
まぁ、勉強しないといけないことは無限に出てくるよね...
そして、なんだかんだで、この記事を書くのにも1ヵ月ぐらいかかっとるやん...時間がいくらあっても足りないというのに、何か、徒労感しか無いっすわ。
ということで、モチベーションダダ下がりですが、Swift について調査していくしかないかと～。レッツトライ～。
Swiftって？
では、改めて、Wikipediaさ～ん！
Swift（スウィフト）は、アップルのiOSおよびmacOS､Linuxで利用出来るプログラミング言語。Worldwide Developers Conference (WWDC) 2014で発表された。
アップル製OS上で動作するアプリケーションの開発に従来から用いられていたObjective-CやObjective-C++、C言語と共存することが意図されている。
⇧ Objective-C とかと併用できるってことらしい。
Swiftは、マルチパラダイムのコンパイラプログラミング言語であるが、XcodeのPlaygroundsの上やターミナルでインタラクティブにデバッグする事が可能である。
LLVMとは、コンパイル時、リンク時、実行時などあらゆる時点でプログラムを最適化するよう設計された、任意のプログラミング言語に対応可能なコンパイラ基盤である。当初は、LLVMの名称の由来は、Low Level Virtual Machine (低水準仮想機械) の略であるとしていたが、現在は、何の頭文字でもないとしている。
LLVMは、JavaとJava VMの関係のように、まず仮想機械をターゲットとした中間コード（ビットコード）を生成し、その仮想機械向けコードを特定のマシンの機械語に変換する。この時言語やプラットフォームとは独立した最適化を行う。
この方法によってLLVMは言語からもアーキテクチャからも独立しており、それぞれに特化した、プログラミング言語固有のモジュールと、マシン向けコード生成部を用意することにより様々な言語アーキテクチャーに対応する。
⇧ え、むっちゃスゴイんじゃない？
LLVMは積極的にプロシージャ間最適化を行うとともに、静的コンパイラとしてもJITコンパイラとしても使え、開発の様々な段階で使える多数の部品を持っている（JavaバイトコードとCILフロントエンド、Pythonフロントエンド、グラフ彩色式のレジスタ割り付けモジュール、など）。
JITコンパイラの場合、実行時に不要な静的分岐を最適化する機能があり、これはプログラムが様々な実行時オプションを持っている場合、強力な最適化手法（部分評価）となる。このため、Mac OS X v10.5ではこれを使ってハードウェア機能がない場合にOpenGLパイプラインを実現している。
⇧ どんな言語でも使えるってことかしら、Oh, my gosh！
LLVM自体はC++で書かれており、イリノイ大学で2000年に開発が開始されたものである。ライセンス条件はイリノイ大学/NCSAオープンソースライセンスであり、これはBSDライセンスによく似たOSI認証ライセンスである。バージョン9.0.0からはライセンスがLLVM例外付きApache License 2.0に変更された。
⇧ Apache License 2.0 になったようです、ありがたや～。
なんか、フロントエンドって言葉出てきたんだけど、
dragonegg
LLVMは、もともと既存のGCCスタック用のものより積極的な最適化を行う高性能のシステムとして開発され、GCCフロントエンドがLLVMと動作するように修正された。現在では、GCC 4.6から派生したフロントエンド（dragonegg）を用いてC言語、C++、FORTRAN、Adaをサポートし、Objective-C、Objective-C++、Goがおおむね動くとしている。
Clang
しかし、LLVMへの興味が広がるにつれ、まったく新しいフロントエンドを多数のプログラミング言語向けに開発しようという動きが出てきた。もっとも注目されているのはC、C++、Objective-C、Objective-C++をサポートする新しいコンパイラClangである。
主にアップルのサポートを受け、ClangはGCCシステムのC/C++/Objective-C/Objective-C++コンパイラを統合開発環境と統合できマルチスレッドをサポートした現代的なシステムで置き換えることを目指している。
GCCでのObjective-C/Objective-C++の開発は衰退気味で、アップルが施した変更は別個にメンテナンスされている。アップルにとっては、自社でコンパイラを開発することにより、第一のObjective-C/Objective-C++実装であり続けながら、LLVMがすでに達成している統合開発環境への統合やその他の現代的な機能への対応といった問題を解決することができる。
⇧ っていう、2つが主流なんすかね？
で、ここで言うフロントエンドって？
フロントエンド（英: front-end）とバックエンド（英: back-end）は、プロセスの最初と最後の工程を指す一般的用語である。フロントエンドは各種入力をユーザーから収集し、バックエンドが使える仕様に合うようにそれを加工する。フロントエンドとバックエンドの結合部はインタフェースと呼ばれる。
⇧ プロセスの始まりが「フロントエンド」で、終わりが「バックエンド」であるって、
⇩ コンパイルっていうプロセスで考えた場合ってことかな？
コンパイラでは、フロントエンドがプログラミング言語のソースコードを中間表現に変換し、バックエンドはそれを変換して機械語などの出力言語のコードを生成する。
バックエンドはより高速に動作するコードを生成するよう最適化を施すのが普通である。フロントエンドとバックエンドに分割することで、フロントエンドはソースコードを扱い、バックエンドが最適化を行うという役割分担ができる。
例えば、GCCはC・C++・Objective-C・Fortran・JavaあるいはAdaといった各種入力言語を共通の中間形式に翻訳するフロントエンド群を含んでいる。
また、バックエンドにはターゲットとなるプロセッサ毎に異なる機械語を生成するものがあるが、フロントエンドはプロセッサの違いを気にする必要はない。
⇧ ってことらしい。
ここで言う「フロントエンド」っていうのは、アプリケーション開発で良く言われる「バックエンド」「フロントエンド」っていう時の「フロントエンド」とは関係なくて、コンパイラでの話ってことみたいですね。
LLVMのイメージ図は、
In very few and basic words LLVM is a compiler framework supporting many different programming language in a “front end” — “back end” multi layer architecture where super easily the first layer parses and lexes the source code generating an intermediate language representation and the second layer converts the intermediate representation to actual assembly machine code optimized for different processor architectures.
Swift, C, LLVM Compiler Optimization - Jacopo Mangiavacchi - Medium
⇧ 上記サイト様が良い感じかと。
LLVMっていうのは、フロントエンド側で、C、Swift、その他の言語のソースコードから中間言語表現（中間ファイルみたいな？）を生成して、バッグエンド側で、x86、ARM、その他、といったプロセッサにアセンブリマシンコードを提供するコンパイラーフレームワークというらしいっす。
LLVM、スゲェ～。
並列スクリプト言語のSwift (並列スクリプト言語)（英語: Swift (parallel scripting language)）とは名称を同じくするが、別言語。
⇧ ややこしいな～。
Apple の開発者向けのページでも、
Objective-Cとの相互運用性
Swiftを使えば、まったく新しいアプリケーションを今すぐ作成したり、Swiftのコードを使用してAppに新しい特長や機能を実装したりすることができます。Swiftのコードは同じプロジェクトの中で既存のObjective-Cファイルと共存し、Objective-CのAPIもすべて利用できるため、簡単に取り入れることができます。
Swiftの利用を開始するには、Xcodeをダウンロードして、「リソース」タブのチュートリアルに沿って手順を進めてください。
⇧ Objective-C との互換性はバッチリってありますね。
Swift は Ubuntu でも使えるようですと
Swift は、Mac（OS X）でしか使えないと思ってたんですが、2016年には、Linuxで使えるようになったんですと。
2019年12月14日（土）現在、
⇧ 対応してるLinuxのディストリビューションは、Ubuntuのみってことですかね？このへんは、2016年3月21日から変わらずってことですかね？
仮想マシンを作成する
というわけで、Swiftを使うために、Ubuntu 18.04をOSとした仮想マシンを用意していきますか～って思ったんですが、Dockerを使えば、Swift（OSとしてはUbuntu 18.04）のコンテナイメージとかが、Docker Hubで準備されとるということみたいなので、今回は、Docker ToolBoxとVirtual Boxの組み合わせで仮想マシンを作成します。
そんじゃ、まずは、仮想マシンを作成で。
docker-machine create --driver [仮想化ソリューション] [仮想マシン名]
指示通りコマンドを実行。
仮想マシンも動いてますね。
仮想マシンの準備はOK。
Swift 環境を用意するとして、何を用意するか？
まぁ、とりあえず、Dockerを使うってことで、Docker イメージを検討。
んで、まずは、Swift のコンテナイメージですが、
⇧ 一応、Swift の公式のダウンロードページにあったDocker Tagと同じ「5.1.2-bionic」ってのを使うことにしようかと。
Swift そのものとは関係ないのですが、せっかくならデータベースと接続してみようじゃないかということで、どんなAPIがあるんかな？
Swift-Kuery is a pluggable SQL database driver/SDK abstraction layer. Its main idea is to unify the APIs to the various relational databases, providing a Swifty yet SQL-like API. This allows easy switching between databases and forms the basis for an Object-Relational Mapping (ORM) framework.
Swift-Kuery-ORM is an ORM, built on top of Swift-Kuery, which allows you to simplify the persistence of model objects with your server.
Swift-Kuery is an easy to learn, consumable framework that comes with a set of implemented plugins.
GitHub - IBM-Swift/Swift-Kuery: SQL database abstraction layer
⇧ IBMさんが、「Swift-Kuery」っていうAPIを作ってて、このAPIは、Database driver や SDK（Software Development Kit）に依存しない抽象レイヤーを提供してくれるもんであると。
PHPでいうところの、PDOみたいなイメージですかね？
Swiftで、ORM（Object Relational Mapping）を実現できる、「Swift-Kuery-ORM」って技術は、「Swift-Kuery」上で構築されとると。
Swift でも ORM（Object Relational Mapping）はできるんであって、
⇧ 「Swift-Kuery-ORM」っていうSwift ORM framework。
⇧ 「Fluent」っていうSwift ORM framework。vapor っていうSwift Web framework の1機能っぽい。
⇧ 「StORM」っていうSwift ORM framework。Perfect っていうSwift framework の1機能っぽい。
⇧ 「ZeeQL」 っていうSwift ORM。
ネットで調べた限り、Webで使うとなると、この4つぐらいがメジャーなんですかね？
ちなみに、VaporでORMとか使わないで、普通にDBとやり取りするのは、MySQLだと、
MySQL (vapor/mysql) is a pure Swift MySQL (and MariaDB) client built on top of SwiftNIO.
⇧ Vaporの一機能として、データベース接続とかできるみたい。
Webの状況は分かったんだが、ネイティブ（モバイルアプリ）だと、
⇧ Realm ってのがイケてるらしいですと。
それと、上記のフレームワークは、いずれもSwiftをサーバーサイドで使うことを想定してると思うのですが、最近SwiftのUI部分のフレームワークであろうと思われる、「SwiftUI」ってのが出たらしいですと。
⇧ なんでも、コーディング量がむちゃくちゃ削減できるっていうんで、期待度が高まってるらしいですと。
な～んか、もしかしたら、サーバーサイド側は、Swift を使わないって流れになってくるのかな、これ～。
そもそもの話、Swiftって元々はネイティブ（モバイルアプリ）で使われてたと思うんだけど、
⇧ サーバーサイドの用途はあんまり想定してなかったってことですかね？
ところで、Webのサーバサイド言語（他にも、GoとかC#とかScalaとか、etc...）だと、
| 言語 | Webサーバ | Appサーバ |
|---|---|---|
| PHP | Nginx、Apache Httpd、LiteSpeed | Apache Httpdのmod_php機能 |
| Ruby | Nginx、Apache Httpd、LiteSpeed | Unicorn |
| Python | Nginx、Apache Httpd、LiteSpeed | Gunicorn |
| Java | Nginx、Apache Httpd、LiteSpeed | Tomcat（Webサーバの機能も持つ） |
⇧ Webサーバとか、Appサーバが必要だと思うんだけど（Webサーバ、Applicationサーバは、これ以外にもたくさんあると思うけど）、Swiftの場合はどうすんだべさ？って思ってググっても情報が出て来なくて、Swiftフレームワークで実現できるよって情報がヒットする...
知りたいのは、フレームワークを使わないでもできるかってとこなんだけど、何かフレームワークを介さないとできんのかね？
⇧ 上記サイト様がまとめてくださってますが、Swiftはサーバーサイドの実装についてはまだ成熟して無いようですかね...
フレームワーク自身がWebサーバの機能を持つってことらしいんだけど、Architectureの概要図みたいのも見当たらないし、ブラックボックス化が半端ない気がするんだが...
⇧ なんか、Nginxと組み合わせれるってことは、VaporのサーバはAppサーバみたいな感じなんすかね？
What does it mean to proxy an HTTP server? In short, a proxy acts as a middleman between the public internet and your HTTP server. Requests come to the proxy and then it sends them to Vapor.
An important feature of this middleman proxy is that it can alter or even redirect the requests. For instance, the proxy can require that the client use TLS (https), rate limit requests, or even serve public files without talking to your Vapor application.
⇧ ただな～、ここで言うHTTP serverっていうのが、Vapor内蔵のサーバってことだと思うんだけど、「ウェブサーバ」のことを言ってるのか「ウェブアプリケーションサーバ」のことを言っているのか、まったくハッキリしないんですな...
つまり、何が気になるっていうかと言うと、
- ウェブサーバ ＋ モジュール
- ウェブアプリケーションサーバ
のどっちの仕組みでSwiftが動いてるのよ？ ってことです。
これ以外にもServer Side SwiftにおいてSwiftのアプリケーションを動かす仕組みがあるのかも知らんのだが、
- PHPは、「1.ウェブサーバ ＋ モジュール」のパターンで、
- Javaは、「2.ウェブアプリケーションサーバ」のパターンで
動かすっていうイメージが私の中ではあるんですよ、何分にもITの経験が浅いんで、かなり適当で且つ雑な推測になってしまうんですが。
まぁ、少なくとも、サーバサイドでアプリケーションを動かす仕組みとしては、ザックリと2パターンは存在するんだと。（申し訳ない、後述する、supervisor、systemd での起動を勘定に入れると、4パターンほどになるのかな）
だからこそ、Vaporは、どっちの仕組みでSwiftを動かしてるんだ？ってのが気になったのよね...まぁ、まったく別のパターンで動かしてる可能性もあり得るんだけどね。
こういうところが、ブラックボックス化してるように思えてしまうんですよね...
経験豊富なエンジニアからしたら、『寝言は寝て言え！ブタ野郎ッつ！』みたいな疑問、否、疑問ですらない、『オホホ！愚問ザマスよ、低級の能なしの口たたき氏～』と一蹴されそうですけどね...
ちなみに、「1.ウェブサーバ ＋ モジュール」のパターンについては、
mod_swift allows you to write native modules for the Apache Web Server in the Swift programming language.
mod_swift ✭ Server Side Swift the right way! – mod_swift – Apache modules in Swift
⇧ Apache Httpdのモジュールとして実行できるSwift 版のもあるらしい。
つまり、Apache Httpdでmod_swiftってモジュールを有効にしていれば、Apache HttpdでSwiftを動かせるってことかと。
PHP7が、Apache Httpdでmod_php7 ってモジュールを有効にして動かせるように、SwiftもApache Httpdのmod_swift ってモジュールを有効にすれば動かせるってことですかね。
mod_phpのイメージ図は、
⇧ 上記サイト様が良い感じです。
ちなみに、
⇧ PHPの実行ファイルって種類がいっぱいあったんですね。
脱線しましたが、なので、Swift の実行の仕組みはまったく分からんのだけれど、上記のイメージ図ような感じで、Apache Httpdで動かせるはずであると。
⇧ お！Swift は、アプリケーションサーバでも動く？って思ったら、このSWIFT softwareのSWIFTってのは、『国際銀行間通信協会（こくさいぎんこうかんつうしんきょうかい、英語: Society for Worldwide Interbank Financial Telecommunication）略称: SWIFT』ってことらしいとですと...紛らわし過ぎでしょ...
ちなみ、Application Server（Appサーバって書かれることが多いのかな？以降、本記事内ではAppサーバと言う記載で） ってのは、
アプリケーションサーバ（英: Application Server）は、ビジネスロジックなどを実装したアプリケーションソフトウェアを実行することを専門とするコンピュータネットワーク上のサーバコンピュータ、もしくはそのようなコンピュータ上でのアプリケーションの実行を管理補助するミドルウェアのこと。
⇧ ってあるように、アプリケーションを配置すれば、実行してくれる存在であり、
ウェブアプリケーションサーバは、ウェブクライアントからのHTTPのレスポンス要求を処理するウェブサーバとバックエンドの関係データベース管理システム (RDBMS) を中心とするデータベース中核層への橋渡しを担い、データの加工などの処理を行う。
⇧ ってあるように「ウェブアプリケーションサーバ」は、「Webサーバ」と「Appサーバ」の両方の機能を併せ持つ存在であり、JavaのTomcatなんかが有名ですかね。
まさに、「ウェブアプリケーションサーバ」は、Web界の『選手兼監督』と言っても過言ではないと...Oh, my gosh...
ちなみに、
⇧ Appサーバが何で広まったのかとかは、上記サイト様が分かりやすいです。
そんな先人たちの知恵である、Appサーバの歴史が分かったところで、SwiftにもAppサーバとかあるのかな？って思ったんだけど見当たらないのよね（Server Side Swiftのフレームワークの中のサーバは「ウェブアプリケーションサーバ」ってことなんかな？と思ったんだけど、説明が無いからよく分からん...）
そして、調べていたら、
⇧ supervisor ってのを使って、アプリケーションを常時起動しておく方法もあると。
⇧ systemd のサービス起動ってのも入れると、サーバサイドでアプリケーションを動かす仕組みってのは、
- ウェブサーバ ＋ モジュール
- ウェブアプリケーションサーバ
- supervisor でデーモンプロセス化
- systemd でサービス化
の4パターンぐらいは存在するんだと...
Server Side SwiftにおけるSwiftアプリケーションを動かす選択肢としてどれが適用できるのか、ますます、分からんくなったやんけ～ ！
結局、サーバの件はよく分からんモヤモヤしたままになってますが、一旦、サーバについての調査はこのへんにして。
次はデータベースとの絡みについて。
データベース接続もせっかくだからフレームワークを介さないでいこうかと思って、MySQLコネクタを確認してみたところ、MySQL connector（ドライバ） の対応言語に、Swift版が無いらしい...
MySQL では、JDBC、ODBC、および .Net の標準ベースドライバを提供していますので、最適な言語でアプリケーションを開発することができます。さらに、ネイティブ C ライブラリによって、MySQL を直接アプリケーションに組み込むこともできます。
これらのドライバは、MySQL コミュニティによって開発およびメンテナンスが行われています。
⇧ PHPのドライバも、正式なものじゃないんですね...衝撃です...
っていうか、まさかのコミュニティの頑張りに左右されるという綱渡り感...Oh, my gosh...
将来的に、Swiftのコミュニティの人たちの頑張り如何では、Swiftのドライバも爆誕するかもっていう希望的観測で待つしかないですかね、いつになるのか分からないけど...。
んで、現状だと、
⇧ 「C API for MySQL(mysqlclient)」ってのを使うことになるらしいんだけど、C言語のAPIに限らず、他の言語のAPIを読み込むのには、Swift では「bridging header」ってのを作るらしいんですと。
んで、ググってみたんですが「bridging header」ってのが何なのかの説明が見当たらないんですな...
っていうか、Appleのドキュメント酷いな...
Imported C and Objective-C APIs
Use native Swift syntax to interoperate with types and functions in C and Objective-C.
Overview
You can access and use pieces of code written in C and Objective-C from within your Swift code. After you import an Objective-C framework, a C library, or a header file, you can work with Objective-C classes and protocols, as well as common C constructs, functions, and patterns.
Imported C and Objective-C APIs | Apple Developer Documentation
⇧ え？これが開発者向けのドキュメントの情報すか...インポートすれば使えますって...だから、APIをインポートする方法が知りたいんでしょうに...
で、「bridging header」ってのが何なのかは分からんのだけれど、
A Swift bridging header allows you to communicate with your old Objective-C classes from your Swift classes. You will need one if you plan to keep portions of your codebase in Objective-C. It should be noted that even if you decide to convert all of your code to Swift, some classes or libraries you may use such as SVProgressHUD haven’t been rewritten in Swift and you will need to use a bridging header to use them.
Imported C and Objective-C APIs | Apple Developer Documentation
⇧ イメージ図は上図のような感じらしい。
なんか、「bridging header」ってのは、
⇧ Xcode を使っている前提らしい。
ちなみに、Xcodeとは？
Xcode（エックスコード）は、ソフトウェアを開発するためのアップルの統合開発環境 (IDE) であり、かつてはMac OS Xに付属する形で配布されていた。Mac OS X v10.3のリリースと共に2003年10月24日に初めて紹介されたこのソフトは、NeXTの資産を受け継ぐMac OS Xの初期IDE「Project Builder」を進化させる事となった。
⇧ 統合開発環境（IDE）ってことは、EclipseやIntelliJ IDEAみたいなもんですかね？「アップルの統合開発環境」ってワザワザ明言してるところを見ると、Mac（OS X）以外での使用を想定してないっぽいですね。
Ubuntu で使えないってことかな...Linux（Ubuntuしかサポートして無さそう）でのSwiftの開発のことは、あんまり考えられてないのかね？
んで、Xcodeを介さない場合、
⇧ 「bridging header」が使わずにインポートできると。というか、「bridging header」は使えないってことですかね？
ここまでの話を整理すると、SwiftでC言語のAPIをインポートする方法は、
- Xcodeを使える場合
- Xcodeを使えない場合
- [ライブラリ名]のフォルダを、インポート先の*.swiftファイルと同階層に作成
- [ライブラリ名]のフォルダ内に、「*-lib」「*-includes」フォルダを作成
- 「[ライブラリ名].a」ファイルを*-libフォルダに配置
- 拡張子が「.h」ファイルを*-includesフォルダに配置
- clangのmodule.modulemapファイルを[ライブラリ名]のフォルダ配下に作成、編集
- インポート先の*.swiftファイルで、ライブラリを読み込む
- インポート先の*.swiftファイルをビルド
ってな具合になるらしい...
そりゃあ、道理でPHPを経由したり、フレームワークを使ったりする情報が多いわけだ、こんな面倒なことを毎回やってられんよね...。
というわけで、心を折られたのでフレームワークの機能を使うということに。
でいこうかと。
っていうか、Server Side Swift について思ったことは、どうしていきたいのかっていう方針みたいなのが定まってない感が半端ない気がするんだが...
Swift Server Work Group (SSWG)
The Swift Server work group is a steering team that promotes the use of Swift for developing and deploying server applications.
⇧ SSWG なる団体もあるらしいんですが、肝心のサーバにデプロイする方法の情報が見当たらんかったけども...
ん？
⇧ なんか、IBMが開発してたServer Side Swift フレームワークである、Kitura が開発から手を引くらしい...
Server Side Swiftを調査している最中に、まさかのフレームワークの1つが終焉に向かうのを目の当たりにするとは...絶句...絶句（杜甫）
な～んだかな～、Server Side Swift フレームワークは、Vapor 一択になってゆくのか、それともServer Side Swift フレームワークというか、Server Side Swift 自体が衰退してゆくのか... 雲行きが怪しいな～
まぁ、何て言うか、Appサーバとかあるんであれば（Swiftを動かすんだから、何かしら実行させる処理を担うサーバが用意されてると思うんだけど...）、ドキュメントなりアーキテクト図なんかで説明を作って欲しいかな～。
何かね～...、仮に、仮によ？
『イノベーションによって、これまでに無い、全く新しいサーバサイドでのアプリケーションの実行を実現！』ってなことをやってるんだとしたら、それはそれでスゴイことだとは思うんで、ドキュメントに説明載せてくれと思うわけよね。
よく、まずは結論から言いましょう、ってあるけども、最初の掴みって大事じゃないっすか？システムなら、全体のアーキテクト図ってのが重要な気がするんだけどね、やっぱり絵で見た方が分かりやすいしね。（つまり、ドキュメントで、APIの設計思想なんかのページに、APIのアーキテクト図も載せてくれと）
絵で表すことができるんであれば、まずは絵で表して欲しいかな～、絵で表しきれない部分を言葉で捕捉して説明すれば良いとは思うんだけどね。
というボヤキばっかりになってしまった...反省。
Swift（Server Side Swift の話ね）環境を構築
そんな見通しの芳しくなさそうに見えるServer Side Swiftの環境を構築してみますか。
んで、Dockerコンテナで実現してゆくとして、私は、Windows 10 Homeを使っているので、Docker ToolBoxをインストールしてDockerを使ってますと。（VirtualBoxもインストールしております。）
早く、WSL2（Windows Subsystem for Linux 2）が標準で使えるようになれば、Docker Toolboxも使うことが無くなるのかもしれんのですが。
はい、すみません、脱線しました。
本題に戻りまして、Dockerコンテナの思想は、基本的には1コンテナ内で1プロセスっていう感じらしいので（supervisorとか使って、1コンテナ内で複数プロセスとかも実現できるらしいが...）、Server Side Swiftの環境の完成イメージ図は、こんな感じになるのかしら？
⇧ まぁ、あくまでイメージ図ってことで。（有識者ではないし、Server Side Swiftの仕組みがよく分かってないので）
コンテナは、3つ作る感じです。Nginxコンテナを経由して、ホストOS側のブラウザからServer Side SwiftのフレームワークVaporのサーバvaporを通して、app（swiftアプリ）にアクセスができるんじゃなかろうかっていう目論見です。
結論から言いますと、申し訳ない...実際にやってみたところイメージ通りの完成形には辿り着けんかったっす（涙）。
まぁ、でも、一応、Swift 自体はインストールできてますから～、ですが、中途半端であることは間違いないので、ここからはお時間ある方のみご照覧ください。
⇧ 上記サイト様を参考にさせていただきました。
そんでは、docker-compose.yml のあるディレクトリまで移動します。ディレクトリ構成は、こんな感じ。
んで、Dockerコンテナを生成・起動で、エラー。
Selecting previously unselected package python2.7-minimal. Preparing to unpack .../5-python2.7-minimal_2.7.17-1~18.04_amd64.deb ... new installation of python2.7-minimal; /usr/lib/python2.7/site-packages is a directory which is expected a symlink to /usr/local/lib/python2.7/dist-packages. please find the package shipping files in /usr/lib/python2.7/site-packages and file a bug report to ship these in /usr/lib/python2.7/dist-packages instead aborting installation of python2.7-minimal dpkg: error processing archive /tmp/apt-dpkg-install-smOfgj/5-python2.7-minimal_2.7.17-1~18.04_amd64.deb (--unpack): new python2.7-minimal package pre-installation script subprocess returned error exit status 1 Selecting previously unselected package python-minimal. Preparing to unpack .../6-python-minimal_2.7.15~rc1-1_amd64.deb ... Unpacking python-minimal (2.7.15~rc1-1) ... Selecting previously unselected package python2.7. Preparing to unpack .../7-python2.7_2.7.17-1~18.04_amd64.deb ... Unpacking python2.7 (2.7.17-1~18.04) ... Selecting previously unselected package libpython-stdlib:amd64. Preparing to unpack .../8-libpython-stdlib_2.7.15~rc1-1_amd64.deb ... Unpacking libpython-stdlib:amd64 (2.7.15~rc1-1) ... Errors were encountered while processing: /tmp/apt-dpkg-install-smOfgj/5-python2.7-minimal_2.7.17-1~18.04_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) ERROR: Service 'app' failed to build: The command '/bin/sh -c apt-get -y install vapor' returned a non-zero code: 100
vapor.Dockerfileの「RUN apt-get -y install vapor」で失敗してるらしい。
何か、Swiftのバグ？なんすかね...vaporをインストールしてるはずなんだが...
⇧ なんかまったく同じ現象っぽい気が...私は、swift:5.1.2-bionic を使ってるんだけどねぇ...
とりあえず、Vaporの公式に質問してみたけど、適当な英語だから通じてない可能性あるんよね...
なんか分からんのだけど、Vaporのバージョンで、使えるSwiftのバージョンが決まってるらしいってことなのかね？...でもね、
Vapor supports the same versions of Ubuntu that Swift supports.
⇧ vapor 3.0 の説明だと、SwiftがサポートしてるUbuntuと同じバージョンをサポートしますわ、ってあったんで、
swift.org を確認したら、
⇧ ってなってますやん？
普通に考えたら、「vapor 3.0 + Ubuntu 18.04 + 5.1.2-bionic」でいけると思っちゃいませんか～？
少なくとも自分は完全に思いましたけどね...そのせいで、むっちゃ時間を無駄にしましたけどね（涙）
そしたらね、
To use Vapor on Ubuntu, you will need Swift 5.1 or greater. This can be installed using the toolchains available on Swift.org
⇧ vapor 4.0 から、唐突にバージョン明示してきたのよね...やっぱり、こういうところを曖昧にしてるドキュメントは宜しくないってことに気づいたんかね？
ほんと、曖昧なドキュメントは認識齟齬を引き起こすし、誰の得にもならんからちゃんと書いて欲しいかな...
なので、vapor 4.0 のインストール方法に切り替えました。
ですが、
Fixed by #1959. More breaks will happen though as our master branches are unstable.
vapor 4 compilation failure · Issue #1960 · vapor/vapor · GitHub
⇧ master ブランチは安定してないらしく、コンパイルが失敗することはあるって...
[451/453] Compiling NIOHTTPCompression HTTPDecompression.swift
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "/toolbox/.build/checkouts/swift-nio-extras/Sources/CNIOExtrasZlib/include/CNIOExtrasZlib.h"
^
/toolbox/.build/checkouts/swift-nio-extras/Sources/CNIOExtrasZlib/include/CNIOExtrasZlib.h:17:10: error: 'zlib.h' file not found
#include <zlib.h>
^
/toolbox/.build/checkouts/swift-nio-extras/Sources/NIOHTTPCompression/HTTPDecompression.swift:15:8: error: could not build C module 'CNIOExtrasZlib'
import CNIOExtrasZlib
^
[452/453] Compiling CMustache mustach.c
ERROR: Service 'app' failed to build: The command '/bin/sh -c swift build -c release --disable-sandbox' returned a non-zero code: 1
</zlib.h></module-includes></module-includes>
Dockerfile実行失敗！
何かね、ライブラリが足りてなかったらしい...まぁ、例のごとくドキュメントに現れてないんだわ...
なので「zlib1g-dev」ってライブラリは必要っぽいですと。
んで、っていうか、Vapor 4.0 のバグなのか知らんけど、new コマンドが機能してないんすわ...
とりあえず、issue 投げました。
というわけで、やりたいことは全く達成できなかったんだけど、
Step 6/17 : RUN swift --version ---> Running in 103f74f1f311 Swift version 5.1 (swift-5.1.2-RELEASE) Target: x86_64-unknown-linux-gnu Removing intermediate container 103f74f1f311 ---> 751d26f5ebd6
⇧ Swift 自体は、バージョン表示されたので使えるであろう。
Server Side Swift は、かなりフレームワークに依存してしまう（特に、Appサーバ、DB接続なんかかな）ので、フレームワークが安定してくれないと実際に使っていくのが怖いな～、って思いました。
あくまでペーペーエンジニアである私の意見ですが（Swiftも今回初めてどういうものか知ったぐらいなので。）
一応、動かないんだけど、軌跡として、GitHubに上げときました。（Vapor 4.0 のnew ができれば動くかな？とは思うけど、検証できてないです。データベース接続とかのコーディングとかも、vapor でプロジェクトが newできないと始まらんしね... ）
というわけで、今回も時間だけを浪費して、モヤモヤしか残らなかったけどもね（涙）。
今回は、このへんで。
