タイトル/名前 | 更新者 | 更新日 |
---|---|---|
技術/"暗号技術入門"読書メモ | msakamoto-sf | 2020-09-05 10:37:18 |
日記/2019/05/06/減量終了、4/18時点の結果 | msakamoto-sf | 2019-05-06 10:47:11 |
技術/Security/OAuth | msakamoto-sf | 2019-05-03 00:38:45 |
日記/2019/03/31/AC7の攻略メモ | msakamoto-sf | 2019-03-31 20:53:15 |
技術/HTML/SVG参考メモ | msakamoto-sf | 2019-02-09 18:00:03 |
日記/2019/01/13/ソースコードの内面化 | msakamoto-sf | 2019-01-13 23:28:45 |
Java/JREをバンドルしたJavaのパッケージング、あるいはインストーラの作成(2019-01時点参考URLメモ) | msakamoto-sf | 2019-01-12 20:38:02 |
日記/2019/01/12/"HTTPS" Proxy (クライアントとプロキシの間もSSL使うタイプ) | msakamoto-sf | 2019-01-12 19:18:57 |
Java/diff(差分検出アルゴリズム)のJava実装調査メモ | msakamoto-sf | 2019-01-06 14:38:22 |
Java/Markdown処理系, asciidoc処理系のURLメモ | msakamoto-sf | 2019-01-05 14:09:04 |
"暗号技術入門"読書メモ。
非常に分かりやすい「入門書」で、おすすめです。
まず図が豊富で文章も簡潔丁寧。あまり詳細まで踏み込まず、基本コンセプトに絞って解説してくれているので概要を把握するにはもってこいです。
そしてなにより、「なぜこの技術が開発されたのか?」「他の技術とどう関連して使われているのか?」「どういう課題が発生するのか?」「その課題を克服するためにどういう技術が編み出されたのか?」という、技術の目的とその積み重ねを丁寧に追っていく点が素晴らしいです。
例えばPKIとは何かという疑問に対して、「PKIとは○○だよ」と教えてくれる資料はたくさんあります。
しかし、「なぜPKIが必要だったのか?PKIで克服しようとした課題はなんだったのか?PKIを導入しても解決できない課題はなにか?」という部分まで解説してくれるのが本書です。
さらに、それら要素技術がどのように組み合わされて実用化されているのか、PGPやSSLを例に応用例を分かりやすく示してくれています。
どの技術も、それまでの技術の積み重ね、「巨人の肩に乗った」成果ではあります。そしてこの本は、暗号技術に付いての積み重ねを分かりやすく俯瞰し、把握できるよう工夫されています。
個別の要素技術について調べていっても、どう繋がっているのか全体像が見えづらくてモヤモヤしている方に、特におすすめです。
日記/2018/12/31/減量折返しポイント通過中 + 2018年まとめ から引き続きやっていた減量だが、4/18に終了した。
2018-09-01 から始めたので、ほぼ8ヶ月に及ぶ結果、73kg台前半に到達した。BMI標準体重 71.3 kg には届かなかったが、+2kg程度なので許容範囲とする。
6週間コースを5周したわけだが、当初計算上は 1周6週間で 4kg 減量できる見込みだった。
しかし実際にやってみたところ、後半は年末年始の行事や風邪でのお休みなどもあり、さらにトレーニング自体に体がなれてしまったらしく(トレーナー談)、1月後半~2月あたりは減量ペースが1周あたり2kg程度までかなり落ち込んだ時期もあった。
そこで、トレーナーからのアドバイスもあり有酸素運動(20分程度の早歩き)を追加してみたところ、どうにか1周あたり3kg程度の減量ペースまで回復できた。
ただし、BMI標準 + 2kg程度にもかかわらず体脂肪率は未だに30%をちょい切って29%程度。こちらが問題だ。
もともと筋肉がつきにくいのか、去年2周ほど回してみた筋肉増量系のトレーニングはほとんど効果が出なかった。
よって、やはり有酸素運動をメインに据えて、今後は体脂肪率を削っていくことに専念すべきかもしれない。
成人男性で健康的と言えるのは20%未満らしいのだが、うーん、そこまで削るとマラソンランナー的なガリガリ体型になるかもしれない・・・。とはいえ、せめて20%台を安定キープまで持っていきたい・・・。
GW連休で少しリバウンドもしてる。8ヶ月近く続けた食事制限の影響か、胃が小さくなった気もするので、食事量はあまり大食いに戻さず控えめ意識を続け、有酸素運動メインのトレーニングに挑戦してみたい。
OAuth勉強用リンクメモ。
JSONによる暗号処理関連:
アサーション, SAML, JWT との関連:
PKCE関連:
Proof of Posession (PoP: 所有証明)
OpenID Connect:
簡単な読書メモ(間違ってる可能性もあるので参考程度に)
全体的にOAuth 2.0を幹とした関連仕様/技術が広がっているが、その関連仕様はなぜ作られたのか、OAuth 2.0だけでは解決できないどのような問題を解決しようとしているのか、またそのためにどういう技術を使っているのか、というのが分かりやすく書かれているのが良かった。
また実際に動く簡易的なシステム一式をJavaScriptのサンプルコードで示し、OAuth 2.0や関連仕様のエッセンスをソースコードで解説してくれるのもユニークであり、またポイントを押さえた解説がありがたい。
おそらく原著の影響と思われるが文章がやや冗長なところはあるものの、2019年時点で OAuth およびそのエコシステムをここまで包括的に解説してくれる書籍は貴重。
今から始めると用語だけでも迷子になりそうな OAuth エコシステムの世界で、分かりやすく整理された道標を示してくれる一冊となっている。
自分がAceCombat7(AC7)で、キャンペーンモードをクリアしたときの攻略メモを整理しました。
キャンペーンモードのストーリー内容・ネタバレなど含まれてますので注意してください。
https://docs.google.com/spreadsheets/d/1DoDbSsDh0MQbeBQPS7O9eXj_9dIJW6Wa-dF2QDdZv5Y/edit?usp=sharing
MDNのSVG資料:
入門記事:
SVG viewBox属性について:
塗りつぶしを透明なしにしたい:
<rect x="130" y="80" rx="10" ry="10" width="60" height="30" stroke="red" stroke-width="2" fill="transparent" />
塗りつぶしを半透明にしたい:
SVG image 要素の注意点:
ブラウザ上でSVGを画像化したい:
Raphaelというのが老舗で、開発者が同じで Snap.svg というのが新たに作られたみたい。
比較記事:
2019年2月現在、確かに Snap.svg のプロジェクトは活発であるとは言えない。githubのTOPページで build failing が出たままで放置 + 最後のcommitが2017年というのが若干不安。
完成しているといえば完成しているのかもしれないが・・・。
仕事ではレガシーIEはもう使っていないこともあり、raphaelを使う必要性は今のところ感じられない。今後の仕事でも、レガシーIE(IE8-9)を相手にすることは無いだろう。
他のメジャーどころとしては、D3.jsなどはグラフやデータのビジュアライズに特化してる感じ。Two.js はWebGLやCanvasにも対応したシンプルな感じ。
raphael と Snap.svg の比較に疲れたら、SVG.js のほうが良いかもしれない。
この歳になってようやく気がついたが、数年に渡りほぼ自分一人でメンテナンスしているソースコードは、自分そのものだ。
自分の内面的な思考が染み付いていて、どこになにがあるか全て把握し、日々の生活(開発作業)が行われる、家であり寝室であり台所であり浴室でありトイレである。
そもそも会社からの帰り道やプライベートタイム、ましてやお風呂に入ってる間に思いついたり練ったアイデアが展開されているのだから、その点からも自分の内面・プライベートがそのまま延長されたテリトリーであり縄張りである。
そのためか、土足で上がってくるようなエンジニアを想定すると自分でも驚くほど攻撃的な感情が湧く。それは「俺の家で勝手に何してやがんだ!」という感情が最も近い。自分のモノであり、また自分そのものでもある家。それを主人に断りもなく勝手に上がり込んでこちらの流儀などお構いなしに散らかすような人間を想定すれば、怒りが湧いても当然といえる。
逆に、「他所様の家に上がらせてもらってる」という謙虚さが感じられる相手であれば許容できる。具体的には、相手の中の常識や流儀で家を使うのではなく、「お宅の流儀を学ばせてください、お宅ではどうやってますか?これはどう使っていいのですか?」と、こちらの流儀を聞いてくるような相手であれば信頼できる。
少なくとも、どうやら自分は、そう感じてしまうタイプらしい。
もちろん、特に仕事で開発しているものであれば、ソースコードは製品であり、自分そのものとして扱うわけにはいかない。
とはいってもなんだかんだの事情と歴史で、できる範囲で「自分色」は薄めてきたつもりではあるものの、フレームワークの手当が薄いとどうしても自分が作ったオレオレ流儀の部分が大きくなってきてしまう。
例えるなら、もともと売家として自分一人で建て始めた家だが、当面は自分一人しか住まないこともあり、自分が住みながら内装や部屋を増改築している間に、どうしても自分にとって居心地がいいように作ってしまったところが多い。
これをチーム開発に適合させるにはどうすればいいか?
自分一人の内面と濃密に結びついた、内面そのもの。これに入ってくるには、新しい人も相当なストレスというか居心地の悪さにさらされる可能性が高い。
扉の開け閉め、便器の蓋の開閉、トイレットペーパーのブランドや交換方法、台所での細かい道具の使い方、お作法、e.t.c...
それら全てに、それまでただ一人の住人であった自分の内面・価値観・判断基準が染み付いていて、まずはそれに従わないと、家に居させてもらえない。
あるいは、自分がその人を受け容れられなくなってしまう。
そうした感覚無く、「俺は私は」で自分の考えを自分の流儀で設計・コーディングしていくようなタイプはどうしても排斥したくなってしまう。
他者の意見は参考にするなり受け入れる方が良い。
だが、同時に家全体のメンテナンスや維持という責任がある。
家全体の設計の統一感・メンテナンスの容易性を実現するために、絶対に守るべきラインがあるし、絶対とは言わないけどなるべく守ってほしいラインがあるし、妥協できるラインもある。
重要なのは、そのラインが今の所、最初の住人であり数年に渡り家を建て増ししてきた自分の頭の中にしかない、ということかもしれない。
文書化するか、あるいはそれこそつきっきりでペアプログラミングするなりして、自分のお作法・判断基準のラインを徹底的に新しい入居者に叩き込むというのもありだろう。
それでも当面は家全体の責任を負うのが自分であれば、自分が100%納得するか、ある程度妥協できるソースコード以外は全てリジェクトする他ない。
作品というのはそういうものだろうし、今の所もっとも内面が反映され作品としての統一感を出しているのが自分であり、またぼちぼちユーザが使っている以上、自分が納得するか、納得の上で妥協するもの以外は出せない。
というか、出してしまうと、作品としての統一感が崩れてしまったり、結局のところ居住者にとってそこが永遠にストレスになってしまう。
そこだけルールが異なるのだ。
ソースコードは、機能を売るものではあるが、同時に開発者にとっては「棲家」だ。
必要なものがどこにあるか、どういうコンセプトで家具は配置されているか、どこにコンセントがあるか、あるいはどこにコンセントがあるように作られているか、天井の高さは、照明は、床の材質は、家具とのこすれは考えられているか、e.t.c...
これを整えようとすれば整えるほど、整えた人の内面や価値観、判断基準が色濃く生活空間に染み付いてしまう。
避けようが無いのかもしれない。
そのかわり、うまくマッチすれば居住者=開発者のパフォーマンスを最大限引き出すことができる。
とはいえ、全てが「オレ流儀」というわけでもない。
フレームワークを使っていればフレームワークの、ライブラリを使っていればライブラリの、あるいは使っている言語で一般的なスタイルの、それぞれの流儀がお互いに主張する。
それをうまくコーディネートするのも開発者の腕の見せどころだろう。
そういった外部が推奨する流儀やスタイルは、いわば「モジュール化」だ。
ある程度一般化されており、他の人も容易に馴染むことができる。
見慣れた玄関、見慣れた照明スイッチ、見慣れた便器、見慣れた水道蛇口、見慣れたガスコンロ。
別にその家の主に確認を取るまでもなく、自分の経験で問題なく使えるし、主もそれを許容している。だって主も同じように使ってるのだから。
例えば、フレームワーク/ライブラリ/言語のお作法が 3 割で、残りが「オレ流儀」のクラス設計や命名規則などになってたとしよう。
そうなると、他の人が違和感なく作業できる領域が3割で、ほかは逐一、「オレ」にお伺いを立てて「この場合どうしてますか?」と聞かないと、「オレ」は機嫌を損ねてそいつを追い出そうとしてしまう。「オレのやり方を聞かずに、何勝手に自分で使おうとしてるんだ」と。
この状態ではチーム開発は覚束ない。
いくつか解決方法はあると思うが、個人的に挑戦するなら、フレームワーク/ライブラリ/言語のお作法を7割、いや8割程度まで高めて、残りを「オレ」の、流儀ではなくアイデアだけに絞り込む。
つまり「お作法」や「流儀」は可能な限り一般化されたモジュールを使うことにして、本当にコアの思考や言語化し辛い設計の勘所だけを属人性の塊として残す。
実際は「フレームワーク/ライブラリ/言語」が5割、「DDD/関数型プログラミング」などのパラダイム・哲学が3割、「コーディングスタイル・命名規則」が1割で、ここまでが全て一般的に受け容れられているものにして、「オレ流儀」じゃなくて「オレの思考」を残り1割に絞る。
こうすれば、他の人(= 新しい入居者)は「オレ」のお伺いを立てる気苦労がずっと減り、一般化されて学ぶ価値のあるフレームワークやライブラリ/言語/プログラミングパラダイム/コーディングスタイルなどを勉強してすばやく馴染むことができる。
そうなれば、家の増改築は「オレ」一人の仕事ではなくなり、近しいスタイルで力になってくれる戦力が増えるだろう。
気をつけなければならないのが、「オレの常識」を振りかざすのは良くないが、かといって作品等しての統一感を崩すのはもっと良くない、ということ。中長期的なメンテナンスビリティに影響が出てしまう。
理由を示すのが重要だろう。なぜ今はこんな「オレの常識」に従う必要があるのか。それは長期的にどう変わっていくのか。なぜ理不尽で不合理な「オレの常識」に従う必要があるのか。
それはひとえに、自分が売り物としての家のコンセプト・全体設計・品質に責任を負う以上、自分が納得できないものは絶対に入れられない。そうである以上、今は自分のこれまでの判断基準の積み重ねとしての「お作法」「流儀」を学び、まずはそれを真似ることに徹してほしい。
徐々に「オレ独自」の色を削っていく。そうすることで、お互いに納得度の高い仕事をできるようになる・・・多分・・・そうなるといいなぁ・・・。
このようなことをつらつら考えるに、やはり息の長いアプリケーションでは、ある程度大きなフレームワークの方が良いかもしれない。
フレームワークが小さいと、不足部分を手作りすることになり、そこで初期開発者の内面が色濃く出てしまう。
そうではなく、大きめのフレームワークを選択して、初期からフレームワークの流儀にうまく従うことで、初期開発者の内面の色付けを押さえて、入りやすいものにできるのかもしれない。
とはいっても、大きいフレームワークって結局そのフレームワークの開発者たちのお作法や流儀の塊なので、それを学んで適切に使いこなすのがまた一苦労なのだけれど・・・。
そんなことをつらつら風呂に入りながら考えていた。
背景:
この辺の、2015年・・・Java8が出る前後くらいの時代の、方式やツール類が比較的よくまとめられてるのが以下:
とはいえ2019年になりJava8がEOL、Java11がLTSとなった今、javapackagerに頼ることは(少なくともFXアプリを作るのでなければ)厳しい。
一応、Java11にポーティングされたjavapackagerが単体であるにはあるらしく、それを使ったビルド方法の解説記事もあるが・・・ちと厳しいかなぁ・・・。
仕事柄触ってる有名どころのJavaアプリ + インストーラとしては、PortSwigger の Burp Suite がある。これ、インストーラのEXEが提供されてて、インストールするとjarとjreがバンドルされてて、OSのアプリ一覧(Windowsならスタートメニュー)にも登録され、簡単に起動できる。
Burp Suite の場合、INSTALL4J という商用製品を使ってるらしい。C:\Program Files\BurpSuiteCommunity\.install4j というフォルダができてて、そこにいろいろ入ってた。
良さそうではあるが、有償なのが敷居が高い・・・。製品というわけでもなく、社内でちょっと使う程度のツールでどこまで金を出せるか・・・。あと、OSS作りたいとか。
もちろんJava開発陣も javapackager が無くなったことは気にしてるらしく、以下のJEP 343でjavapackagerと同等で、もうちょっとシンプルなパッケージングツール作りたいね、という話は進んでるらしい。
が、さすがにこれのリリースを待つのは気が長すぎる、現状の範囲内でJava8~Java11の移行期を乗り切れる無償の、できればOSSフレンドリなツールはないか?
→とりあえず見つかったのが以下。
Win7環境とちょっと古い記事になるが、実際に3種類試した人が記事書いてくれてた:
ただ、上記記事では JSmooth と exewrap が若干微妙なところがあるらしい。起動後しばらくしてマウスカーソルが砂時計になったり(JSmooth)、jvm.dllがロードできない(exewrap)など。
以下はexewrapを使って配布パッケージを作ってみた人の記事。ここでは問題なさそう。
ざっとググった主観だが、利用者と実績が一番多いのは Launch4j に思える。StackOverflowでの質疑応答も多いっぽい。
また、exewrapはWin専用だが、Launch4j はMacも対応している(要 Xcode)。
Launch4jはJREバンドルも対応してるようなので、最も無難な選択肢に思える。
Launch4jを使った記事の参考:
また、Java9でのモジュール導入により、Java11にもなれば jdeps + jlink で必要なモジュールのみでJREの容量を削減できらしい。これも Launch4j と組み合わせられると嬉しいかも。
機会があれば、Launch4jちょっと触ってみたい。GUIだけなら単体で動かせるようだが、Mavenプラグイン経由となるとどうもMinGWが必要っぽいのでそのあたりの差異も試してみたい。
以上。
昔からのHTTPプロキシでは、HTTPSの場合、最初にクライアントからプロキシに HTTP (= 平文) でCONNECTメソッドのリクエストを送り、プロキシではHTTPSに接続を切り替えてUpgradeレスポンスを返す。
ただ、これだと少なくともHostが平文でネットワーク上を流れてしまう。
2019年1月時点のFirefox, Chrome, curl 7.52.0 以降では、ブラウザ/クライアントから、最初からHTTPSでプロキシにリクエストする "HTTPS" タイプのプロキシがサポートされている。
Firefox:
Chrome:
curl 7.52.0 以降
IE/Edge/Safari/Android/iOSでの対応状況は不明。
以前から SwitchyOmega や FoxyProxy など Chrome/Firefox用のプロキシ切り替え拡張で、プロキシの設定画面でschemaの他にタイプとして HTTP/HTTPS/SOCKS4/SOCKS5 あたりが選べるようになってて、「HTTPとSOCKSはわかるけど、HTTPSってなんじゃらほい・・・?」と不思議に思ってたのが、どうやらこれらしい。
どういう仕組で動いてるかは試したわけじゃないので確証は無いが、Chrome側の上記URLで、簡単に試すために通常のHTTPプロキシとして動作してるSquidに対してstunnelでSSLトンネリングしかければ、HTTPSでプロキシできるらしい。ということは Squid のCONNECT -> Upgrade の流れがそのままHTTPS(というかSSL)になっただけと思われる。SquidとしてはUpgrade返したあとは中の通信は素通しになるので、まぁ最初からHTTPSなら、Squid側としてはなんら変わることが無いのだろう。
Squid自体も https_port あたりの設定値でネイティブに HTTPS プロキシをサポートしているようなので、それで試しても良いかもしれない。
これ、httpスキーマについてもHTTPS プロキシで通せるのかな? クライアント <> プロキシ間はHTTPSで、プロキシ <> ディスティネーションサーバ間はHTTPになるイメージだけど。
もしそれも可能なら、プロキシの利用者を制限するためにプロキシ認証を使いたいけどプロキシ認証の通信経路は暗号化したいときに最適かもしれない。
最大の難点は対応ブラウザやクライアントが限られること。とはいえ、Chrome/Firefoxで現時点で普通に動くので、一般ユーザ向けであれば採用しやすいかもしれない。アプリ間通信に使うのはcurl以外の対応状況が不明なので厳しいかな?
あと、「これで通信先を完全に隠せる」かというと、そうは行かない気もする。多分 ブラウザ -> プロキシへの最初のHTTPSで、今なら普通にSNIを送るのではなかろうか?そうなると TLS Client Hello パケットの中に平分で最終ディスティネーションのホスト名がSNI拡張フィールドに含まれるため、盗聴されていればどこに接続しようとしているのか、までは見えてしまう。
以上、メモ。
Java実装のMarkdownパーサライブラリのURLメモ。
Markdownの仕様 : 2018年にもなると、CommonMark と GFM (Github Flavourd Markdown) がメジャー?
Java実装ライブラリ:
Markdownではないが、Asciidoctorも良さげ。