SSH (secure shell) とは、外部のコンピュータへ安全にアクセスする方法のこと。
より正確には、安全でないネットワークを介しながら、安全なリモートログインと安全なネットワークサービス (shell操作など) を実現するためのプロトコル。
Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.
RFC 4251
べんきょうちゅう
典型的にはTCP/IP上で通信を行う。しかし必ずしもTCP/IPに限定されるわけではない (reliable data stream上であればよい)。
The transport layer will typically be run over a TCP/IP connection, but might also be used on top of any other reliable data stream.
RFC 4251
SSHを利用したアプリケーションとしてはOpenSSHがデファクトスタンダード.
接続先情報などを明示的にコマンドラインを介して、あるいは暗示的に設定ファイルを介して与え、リモートホストへ接続する。
設定ファイルには名前付きssh設定を複数用意しておけるので、とても楽になる.
ホストから渡された秘密鍵でAuthZだとホストごとに引数変えたりしなければいけないので、とても重宝する (EC2とか).
設定ファイル(ssh_config - OpenSSH SSH client configuration files)は以下の優先順位で2種類
Windowsにはsshクライアント (OpenSSH) がプリインストールされており、PowerShellから呼び出せる.
PS > Get-Command ssh CommandType Name Version Source ----------- ---- ------- ------ Application ssh.exe 7.7.2.1 C:\WINDOWS\System32\OpenSSH\ssh.exe
正確には、Windowsの Features on Demand (FODs、オンデマンド機能) として、OpenSSH Clientが公式に用意され、Windowsにプリインストールされている。
プリインストールはApril 2018 Updateから [ref].
関心の分離 / separation of concerns、SoC
密結合とは
関心が分離しても密結合みたいなケースはありうるか
上位と下位が頭を固くしてる気がする。ブラックボックスでいいんじゃない？
interfaceが重要、は大原則。
アーキテクチャ: 線引きのベストプラクティスを教えてくれる.
関心の分離はほって置くと失われるもの.
自動化された回帰テスト?
前提:
“内部ビジネスロジック”
”外部エンティティーとのやりとり”
は別の関心
Robert C. Martin (Uncle Bob). 2012. The Clean Architecture. link
低レベルな具象的部分が、高レベルの抽象的な方針に対し、依存する、という依存ルール/The Dependency Ruleを明確に示した。
ヘキサゴナルアーキテクチャ・オニオンアーキテクチャ等はいずれも関心の分離を達成するためのアーキテクチャである。
これらアーキテクチャの方針を統合し、実現可能なアイデアとしたもの1がクリーンアーキテクチャ.
肝は依存ルール.
それを実現する技術として依存性逆転の原則を紹介。
抽象度による4段階の切り分けは本質ではない、と明記されている。
Only Four Circles?
No, the circles are schematic.
You may find that you need more than just these four.
There’s no rule that says you must always have just these four.
本質は、依存ルール、すなわち依存性の方向。
常に、低レベルで具体的な詳細部が、高レベルの抽象的な方針に対し、依存する。
The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards.
...
However, The Dependency Rule always applies.
Source code dependencies always point inwards.
ドメインモデルを独立せよ
ただ、本質的には ドメインモデルがどこにも依存しない形で書ければあとは誤差
DDDに関する質問にバシバシお答えしました [ドメイン駆動設計] - Qiita
The diagram at the top of this article is an attempt at integrating all these architectures into a single actionable idea. ↩
[caller/callee・ブラックボックス・interface]
小さなブラックボックスを組み合わせて大きいシステムを造る
calleeが内部でcallerを操作するな、calleeは変数を返すだけにしろ(まさに関数型)
[ブラックボックス: 暗示的外部操作をしない]
暗示的に外部を操作した場合、エラー解析のためブラックボックスを開く必要がある
外部にある何を、どんな条件で、どのように変更するか開けないと (明示されていないために)わからないから
あけたらそれ、ブラックボックスちゃうやん
[引数によらない状態変化がもたらすデメリット]
いつ変わるか調べるの大変 (怠惰に反する)
X = "new"とかx.y = "new"とかf(X)とか書いてあったら、"x = || (x)"で検索かけられなくもない
関数のほう死ぬほどいやだけど
明示してあれば、引数によらんでも一緒か。関数理解は大前提だし
y = x, f(y)されたら引数型でも同じくらい手間がかかる
[ブラックボックス間の協調]
変数変換
イベント
型不明オブジェクトを外部から受け入れる (引数、暗示的依存とわず) 場合、
・オブジェクトがどうなっているか
・property Xを持つか
・処理中に外部から変更されるリスクはあるか
を考慮すべきである。すなわち外部を全て理解し考慮しないといけなくなる (つらい)
-> 外部interfaceの明示
[必要条件と十分条件を誤解させる言い方はさけよう]
なんか呼ばれたので処理して返すよ
実装:
Unity & Node.js使いなら、最速5分でできるよ。
Unity (client) 側はwebsocket-sharpを、Node.js (server) 側はwsを使う。
Unityアプリの画面click回数をserverへ送るテストコードを書くものとする。
websocket-sharpをgit cloneして落としてくる。
不要なExamples (多分3つほどある) ディレクトリを削除する。
slnファイルを開き、ビルドする。
websocket-sharp/binの中にdllファイル(websocket-sharp.dll)があればOK!
この1ファイルがUnity側のすべてを担ってくれる。すごい。
適当なディレクトリでnpm initしておき、.jsファイルを作成する。
npm install wsでライブラリwsをインストールする。
あとはWebSocketサーバーのコードを書くだけ。最小なら5行ほどで終わる。
const WebSocketServer = require('ws').Server; const wss = new WebSocketServer({ port: 8080 }); wss.on('connection', (ws) => ws.on('message', (message) => console.log('received: %s', message)));
かけたらnode (filename).jsでとりあえずサーバー走らせとけば準備完了
次はclient側のUnity. 先のwebsocket-sharp.dllをコピーし、Unity editor上からAssetsの好きなところへ入れる。
こうすることで、C# scriptのusingからアクセスが可能になる。
あとはC#コードを書き、適当なEmpty objectにアタッチするだけ。
コードはこんな感じ。
using UnityEngine; using WebSocketSharp; public class wsClient : MonoBehaviour { private int count = 0; // click counter private WebSocket ws; void Start () { var url = "ws://localhost:8080"; ws = new WebSocket(url); ws.Connect(); } void Update () { if (Input.GetMouseButtonDown(0)) { Debug.Log("clicked!"); count++; ws.Send("clicked No. " + count.ToString()); } } }
Node.js サーバーappを動かした状態で、UnityをRun。画面をクリックするとメッセージが送られるはず。
Node.jsのコンソールでreceived: clicked No. Xと出てきたら大成功！
あとは好きにメッセージを送り、server側からの通信を自力で実装して好き放題だぞえ。
github.com
このサイトで作ってあるデモ。wsさえnode.js側でinstallしとけばそのまま動く.
全自動にしてほしい…
所定の申請先に、所定の書類を提出する。
以下の申請先いずれかに、所定の書類を提出する。
提出方法は直接あるいは郵送。
提出先: 区役所保険年金課
さいたま市／保険年金課の紹介
IFTTT Webhooksを使い倒し、様々なサービスをまたいで自分だけのappを作ろう！
受信 (if側) は簡単、event名を決めて指定URLへJSONをPOSTするだけ！
送信 (then側) はもっと簡単、好きなURLへrequestが送れるよ！
基本的には、event名をつくり、それに対応するURLへrequestする。
event名はifを設定する際に決められる.
ifttt.com
ここのDocumentationにURLが載っている (pathにevent名が含まれているので、そこをオーバーライドする)
あとは任意のサービスからrequest投げるだけ！
GASのUrlFetchApp.fetch関数を使ってweb requestをするだけ！
アクセス制御はURL末尾のaccess keyでしているみたい、ゆるいけどその分使いやすいね.
var data = {
'value1': "your message 1",
'value2': "your message 2"
};
var options = {
'method' : 'post',
'contentType': 'application/json',
'payload' : JSON.stringify(data)
};
UrlFetchApp.fetch('https://maker.ifttt.com/trigger/{event_name}/with/key/xxxxxxxxxxxxxxxxxx', options);
