home ホーム search 検索 -  login ログイン  | help ヘルプ

find 検索

1 - 10 / 1323    1  2  3  4  5  6  7  8  9  10   [>]  [>|][>|]
タイトル/名前 更新者 更新日
日記/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/28/最近の仏教思索, 中学時代の恐怖 msakamoto-sf 2019-01-29 01:27:23
日記/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
ソート項目 / ソート順     1ページ 件ずつ表示

日記/2019/05/06/減量終了、4/18時点の結果  

所有者: msakamoto-sf    作成日: 2019-05-06 10:27:43
カテゴリ:

日記/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ヶ月近く続けた食事制限の影響か、胃が小さくなった気もするので、食事量はあまり大食いに戻さず控えめ意識を続け、有酸素運動メインのトレーニングに挑戦してみたい。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-05-06 10:47:11
md5:1bb5f253514416ea05ebd634ef88e276
sha1:e81b32794adff55ed858347773b6b94c1b6d1354

技術/Security/OAuth  

所有者: msakamoto-sf    作成日: 2012-04-16 00:23:54
カテゴリ: OAuth セキュリティ 

OAuth勉強用リンクメモ。

実装

OAuth 1.0 仕様, 参考資料

OAuth 2.0 及び関連RFC

JSONによる暗号処理関連:

アサーション, SAML, JWT との関連:

PKCE関連:

Proof of Posession (PoP: 所有証明)

OpenID Connect:

OAuth 2.0 参考資料

参考書籍

簡単な読書メモ(間違ってる可能性もあるので参考程度に)

  • フロント・チャネル / バック・チャネル : フロントがリソース所有者とブラウザを介したコミュニケーション。バック・チャネルはリソース所有者を介さない、ソフトウェアだけのコミュニケーション。
  • "Bearer" : この場合、小切手や手形の「持参人」としての意味っぽい。運ぶ人、運搬人、あるいは手紙の使者という意味も持つ。ニュアンス的には、「中身が何かは知らないけど、とりあえず重要な情報を持ってきた人」的な感じになると思う。
    • OAuth 2.0 における Bearer トークンのポイントとして、「クライアントはトークンの中身を解析しない/する必要が無い/できない」というのがある。認可サーバから発行されたトークンを、まさに「中身を知らずにとりあえず持参して運んできた人」がクライアント、という見立てっぽい。
  • クライアントは Bearer トークンの中身を知らなくても、保護対象のリソースサーバは知る必要がある場合もある。特に認可サーバとリソースサーバとで、認可した主体やスコープ、有効期限など細かくやり取りしたい場合。
    • → 認可サーバが発行するトークンの中身を、JSONを使って表現力を高め、さらに署名などの暗号技術を組み合わせることでセキュリティを確保する、そのためにJWS/JWTなどが活用される。
  • ただし Bearer トークンの中身にいろいろ詰め込みすぎると、トークンが漏洩したときの影響が大きくなる。リソースサーバが、アクセストークンをもとに認可サーバに対してトークンの詳細をリクエストする仕組みが「トークン・イントロスペクション」として策定された。
  • 構成時シークレット(Configuration Time Secret) : ソフトウェアを構成する際に組み込まれるシークレット。クライアントID/クライアント・シークレットなど。
  • 実行時シークレット(Runtime Secret) : ソフトウェア実行時に生成・取得されるシークレット。認可コードやアクセストークン/リフレッシュトークンなど。
  • 公開クライアント(Public Client) : クライアント内に構成時シークレットを持つことができない。ネイティブアプリやブラウザ内で完結するアプリケーションなど。これらにクライアントシークレットを埋め込んでも、解析されて容易に取り出されてしまい、秘密のままにできない。
    • 公開クライアントでの認可コード付与方式での認可コードとトークンのセキュリティを強化するために、PKCE(Proof Key for Code Exchange) が開発された。認可コード発行時と、アクセストークンへの交換時に、クライアントが生成したchallenge/verifier を認可サーバとやり取りすることで、認可コードの横取りを防ぐ。
  • 機密クライアント(Confidential Client) : 構成時シークレットを保持できる。Webアプリとしてのクライアントなど。
  • ネイティブアプリはコピーされて複数の場所で動くことから、クライアントシークレットを保持できず、クライアントの認証に難があった。
    • → 実行時にクライアントを動的に認可サーバに登録し、認可サーバ側でクライアントシークレットを発行・管理する仕組みが開発された。これはクライアントからの自己申告的な側面も強いように思われ、認証というよりは、同じクライアントIDに基づく複数のクライアントインスタンスを「識別」するためのもの、と考えたほうが良いかも。
  • OAuth が「認証」ではないのはなぜか?
    • そもそも OAuth におけるアクセストークンは、所有者が認可したあとは、所有者がいてもいなくても使える性質がある。grant type によってはそもそもシステム同士の認可だったりして所有者がいない場合すらある。
    • 認可サーバにおいて認可を下す瞬間に、所有者の認証が行われる保証は厳密には無い。システムによる自動作業の可能性もあるし、そこはブラックボックスであり OAuth の範囲外。
    • つまりアクセストークンがあること、イコール、そのアクセストークンに紐づく「誰か」が認証されたこと、という紐付けは OAuth 2.0 の範囲では取り扱っていない。
    • さらに言えば、アクセストークンのライフサイクルと、「認証」情報のライフサイクルが異なる。また、OAuth 2.0 の思想としてクライアント側はアクセストークンの中身を認知しないため、アクセストークンに認証情報を埋め込み認可サーバからクライアントに情報を伝えるのはできない。
    • → ここにおいて、認可サーバからクライアントに、「認証」イベントの発生と認証情報を伝えるための、アクセストークンとは別のライフサイクルを持ったトークンが必要とされる。これが OpenID Connect における IDトークンとなり、表現力とセキュリティを要求されることからJWTエコシステムの技術が使われている。
  • Bearer トークンはクライアントが中身を知らなくても良い反面、漏洩してしまった場合にクライアントとトークンを紐付けるのが難しい問題がある。(中身を知らなくても使える = 攻撃者の手に渡っても使える)
    • これを解決するために、鍵(公開鍵ペア)をトークンをペアにして、クライアント側でトークンと鍵による署名を追加し、保護対象リソース側で検証することによりクライアントとトークンを紐付けられるようにしたが「Proof of Posession : 所有証明」の仕組みっぽい。

全体的にOAuth 2.0を幹とした関連仕様/技術が広がっているが、その関連仕様はなぜ作られたのか、OAuth 2.0だけでは解決できないどのような問題を解決しようとしているのか、またそのためにどういう技術を使っているのか、というのが分かりやすく書かれているのが良かった。
また実際に動く簡易的なシステム一式をJavaScriptのサンプルコードで示し、OAuth 2.0や関連仕様のエッセンスをソースコードで解説してくれるのもユニークであり、またポイントを押さえた解説がありがたい。
おそらく原著の影響と思われるが文章がやや冗長なところはあるものの、2019年時点で OAuth およびそのエコシステムをここまで包括的に解説してくれる書籍は貴重。
今から始めると用語だけでも迷子になりそうな OAuth エコシステムの世界で、分かりやすく整理された道標を示してくれる一冊となっている。



プレーンテキスト形式でダウンロード
現在のバージョン : 2
更新者: msakamoto-sf
更新日: 2019-05-03 00:38:45
md5:88573ca2d8c3acbf00790a1861943126
sha1:93d25b15612aa321cf85e13411d7fa31da7dfdec

日記/2019/03/31/AC7の攻略メモ  

所有者: msakamoto-sf    作成日: 2019-03-31 20:52:22
カテゴリ:

自分がAceCombat7(AC7)で、キャンペーンモードをクリアしたときの攻略メモを整理しました。

キャンペーンモードのストーリー内容・ネタバレなど含まれてますので注意してください。

https://docs.google.com/spreadsheets/d/1DoDbSsDh0MQbeBQPS7O9eXj_9dIJW6Wa-dF2QDdZv5Y/edit?usp=sharing


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-03-31 20:53:15
md5:a767e2e18394255ab7108a229393c033
sha1:5860e9aec66a7bc2cdeb0e7eda285f6c573880f3

技術/HTML/SVG参考メモ  

所有者: msakamoto-sf    作成日: 2019-02-09 17:59:21
カテゴリ: HTML SVG 

参考資料

MDNのSVG資料:

入門記事:

SVG viewBox属性について:

実際に触ってみた時に遭遇したTIPS

塗りつぶしを透明なしにしたい:

  • fill="transparent"
<rect x="130" y="80" rx="10" ry="10" width="60" height="30" stroke="red" stroke-width="2" fill="transparent" />

塗りつぶしを半透明にしたい:

  • fillは塗りつぶしたい色を指定。
  • fill-opacity="0.5" など、小数点で透明度を指定。同様にstroke-opacityも設定できる。
  • 参考 :

SVG image 要素の注意点:

ブラウザ上でSVGを画像化したい:

JavaScriptライブラリ

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 のほうが良いかもしれない。



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-02-09 18:00:03
md5:821eeac53482f34fb8e75c462db8cd75
sha1:e3ed9772e1d211b113fc7ba1a549d8dcadd9ed6a

日記/2019/01/28/最近の仏教思索, 中学時代の恐怖  

所有者: msakamoto-sf    作成日: 2019-01-29 01:26:17
カテゴリ:

今朝は悪夢で目が覚めた。
悪夢の細かい内容は忘れたが、パターンとしては典型的だ。
中学時代。自分なりにクラス内でのコミュニケーションをやりくりしてきたが、どうも担任の気にそぐわなかったらしく、ふとしたきっかけで詰問が始まる。
担任は最初は穏やかに。徐々に「なんで?」と詰めていき、最後にいきなり怒鳴る。
その時の恐怖。

ただ、今回は覚め方が違った。
詰問の途中で、夢の中の自分が、徐々に持ち上がっていく恐怖を認識した。
そこで「なにか違う」という違和感から急速に「これは夢だ」という認識につながり、そこで目が覚めた。

以前ならそのまま夢は進行し、怒鳴られ、「やはり駄目だったのか」という冷や汗。足の震え。など諸々のネガティブな感覚に津波のように襲われる。

今回はその前に、自分で意識を引きずり下ろした・・・というか引きずり上げた?格好になった。

目が覚めた後のまどろみの中で、なぜこのパターンの悪夢を度々見るのか考えた。
考えられる要因としては、とにかく中学時代にある。
このパターンの悪夢は決まって中学時代で、中学3年間ずっと変わらなかった担任の男性教諭から怒鳴られる、というパターンだからだ。

なぜそれほど恐怖を覚えるのかというと、とにかく「怒りのトリガー」が分かりづらい男性だったことが大きい。
例えば入学後一週間ほどの中での部活動見学だったか・・・とにかく、クラス全員で学校内で敷地に出た。
が、敷地に出て集まったところで、その男性教諭は一向に動こうとしない。何かを待っているかのように動かない。
10分、15分ほどして生徒全員が違和感を感じて落ち着かなくなったころ、「上履きのまま外に出てんじゃねぇよ」と一喝。
全員を一旦校舎内に戻して、上履きを雑巾で水拭きさせた。

些細だが、こんな例もあった。
授業後の掃除が終わり、帰りの会が始まり、その男性教諭が教室に入ってくる。
たまたま掃除当番が片付け忘れたのか、腰ほどの高さの移動棚にゴミが入ったちりとりが置かれたままだった。
その男性教諭はいきなり、「忘れてんじゃねぇよ」だったか、とにかくいきなり不機嫌な言動を発してちりとりごと移動棚をバタン、と倒した。

未だに詳細不明だが、こんな例もあった。
朝の自習後は朝の会に進むのだが、いつまで経っても男性教諭が教室に入ってこない。
クラス会長などが職員室に様子を見に行っても、いない。聞いてみてもはっきりしない。
他の教諭による授業が始まり、やむなく朝の会をなしで一日が終わる。
生徒の噂によると、どうもその男性教諭が、朝の自習時間で別のクラスにたまたまか何かで入ってきたときに、そのクラスの生徒がその教諭を馬鹿にするようなアクションをとってしまったらしい。
それでキレた教諭が、一日中「何か」をそのクラスでしていたらしい。
帰りの会になってようやく顔を見せたその男性教諭は、開口一番、「たまに大きな声だすとスッキリするね」と発言した。
なぜ自分は朝の会に出ず、丸一日すっぽかしていたのかを一切話さずに。

他の男性教諭だが、こんな例にも遭遇した。
その男性教諭は、キレた時の暴力が凄まじいことで生徒間では密かに有名だった。
とはいえ、めったにキレることは無い。
ただ、その男性教諭が担当した体育の授業が終わった瞬間に、いきなり「てめぇ後ろ向いてんじゃねぇ!」とボールが飛んだ。
どうも、授業終了時の挨拶の礼で、後ろ向きかなにか、とにかく「その男性教諭にとっては」気に障るアクションをした生徒が居た、ということ。
その教諭はその生徒をひっつかんで、体育館の用具室に引きずっていってボールを投げつけていた。

・・・書いてて、よく新聞沙汰・警察沙汰にならなかったものだ、と思う。

総じて「キレたときの暴力」が印象的であり、また、「何が原因でキレるか予測できない」という点も恐怖の一因だった。
何しろ、それまで普通のトーンで話していた教師が、生徒のちょっとしたアクションでいきなり「舐めてんじゃねぇぞ」という恫喝的な口調に切り替わるのだ。

そうしたことを思い出しながら、ふと、「あれ、これってDVっぽくね?」と思った。
まず教師と生徒では圧倒的に一方通行の権力構造がある。端的に言って、生徒が教師に反抗するのは、論理的にも物理的にも難しいところがある(と、当時は思っていた)。
教師が怒って、授業を止めてしまったら、困るのは生徒だ。
つまり生徒は教師を怒らせたくない。
教師は、ふとしたきっかけでキレる、つまり豹変する。
ただ、嵐が過ぎればいつものトーンに戻り、生徒との間で笑顔も出てくる。

生徒・・・というか、当時の自分にしてみれば、教師は腫れ物のように扱うしかなかった。
朝の会で、たまたま教室が数分落ち着かなかっただけでキレるかもしれない。
集団行動で、たまたま教師の中のルールに抵触する行動が発生しただけでキレるかもしれない。
しかも、キレ方として生徒たちが自分で気づくまでいやらしく、じっと待つのだ。
でも生徒の方では教師が何も言わずにじっとしてるので、どういう状況が進行しているのかわからない。
ただ一つ推測できるのは、自分たちはまたこの、理解不能な男性教師の機嫌を損ねたらしいということだけ。
それで男性教師が、重たい口を開くのを待つしか無い。

明示しないマイルール。
不機嫌であることを表現し、それを察するように求める圧力。
察することができなかった場合の恫喝・怒り・示威行為。
たまに見せる優しさ。

DV・・・というかなんというか、もうアホな大人以外の何物でもない。

こんなアホで未成熟で救いようの無い教師どもに、中学3年間、心理的・物理的に支配されていたのかと思うと、泣きたくなってくるというか呆れる。
(というか書いてて思ったが、これ、今の御時世だったら速攻で騒ぎになるようなギリギリのラインじゃね?実際、他にも別の男性教諭によるガチの暴力沙汰もあったし・・・マジでなんだったんだあの3年間・・・・)

他の要因もあったが、自分の性格は、中学以降、はっきりと変質した。
自分はふとしたトリガーで昔の嫌な思い出・・・つまり、後悔や恥ずかしさ・恐怖・など諸々のネガティブな衝動に駆られるような記憶が頭の中でフラッシュバックする。
そのときの記憶は、まず確実に中学以降なのだ。
小学校までの記憶は、ネガティブなフラッシュ・バックに出てくることはまず、無い。

また自分の現時点でのコミュニケーションスタイルとか気質なども、かなりの面で中学~高校時代に整備されたが、特に中学時代に大きく作り変えられてる。

それほどに、中学時代の3年間変わらなかったクラスは、小学校までと比べてカオスで、小学校までの常識と自信を散々に打ち砕き、ストレスフルだった。
正直、壊れる一歩手前でなんとか踏みとどまれた。

自分は、今朝までは、それの要因としてクラスのメンバーと自分の生い立ちの相性問題がメインだと考えていた。

今朝、そうではないんじゃないか?と、実に四半世紀ぶりに考え直した。

普段は問題ないのにいつ・何が原因でキレるかわからない、顔色を伺う教師共が絶対的に支配する空間。

彼らが、私の3年間を、踏みにじった。
もしかしたらもっと笑えたかもしれない3年間の記憶を、真っ黒に塗りつぶした。
四半世紀過ぎても悪夢として登場するような、恐怖の「根」を私の心に植え付けたのだ。

私のせいだけじゃない。

教師も、おかしかったのだ。

・・・とここまで考えてきたところで、さらに気づく。
確かに中学時代にいろいろとショックを受けたことで、ネガティブな記憶のフラッシュバックが頻発するようになったかもしれない。
だが、なぜ?

なぜ、「ああ~~~、あのときあんなアクションを取るんじゃなかった」とかそうした後悔するだけの記憶を、フラッシュバックで連発するのか?

一つには、小学校時代まではかなりおしゃべりだったが、逆に、相手のことを考えずに好きなように発言していたことがあり、それへの戒めという面がある。
それは自覚しており、中学になってから、自分の発言に対してストレートな反応、時には暴力的な反応が帰ってくるような同級生に囲まれたこともあり、自分が今までどれほど迂闊に発言し、他人を傷つけていたのかつくづく思い知らされた。
それが、中学を境にした性格の変質の一要因ではある。

ということは、自分への戒めが自動で発動しているとも考えられないか?

二度とあのような真似をしないよう、自分の中で「後悔の感情を生起させる記憶」がストックされていて、ふとしたキーワードに関連して勝手にそれが記憶から引き出されてくるのではないか?

その目的は?
・・・生きること。
生きるために、他人とうまくコミュニケーションを取るために、二度と同じ失敗をしないために、何度も何度も「自分はこうして失敗した」という記憶をフラッシュバックさせて強化学習させる。
それが、フラッシュバックの仕組みではないだろうか。
つまり、自分でも認識の及ばない領域で、「なにか」が必死に生き延びようとあの手この手を弄していて、そのうちの一つがネガティブ感情を誘起させる記憶のフラッシュバックではないだろうか。

小児喘息だった子供の頃からずっと、自分の意識の範囲外で、自分の中の「なにか」が必死に生きようとしていた。
喘息で呼吸が苦しかったときも、
風邪で嘔吐したときも、
喘息の薬を毎日毎日飲んでいたときも、
アトリエに通って絵を描いていたときも、
あのときも、このときも、そして中学での恐怖支配の中でも。
「それ」が必死に生きようと、生き延びようとしていたし、今もそうしている。

「火」
そうとしか、認識できない。
あくまでもイメージの上でだが、生き延びよう、生きようとする圧倒的な熱と光。
中学時代に真っ黒に塗り潰された、でもその片隅にちらほらと残っていた色。それが、この火だったのだろう。
いつもいつも、ギリギリの崖っぷちにいくか行かないかのところで、直感として自分を突き動かしていた「なにか」、それがこの火だったんだ。

自分は、ずっと生きようと、生き延びようとしていたのだ。

そのような認識が発生したとき、歓喜で涙した。

これは煩悩とも違う、どちらかといえば「業」に近いのだろう。
そして・・・もしかしたら・・・初期仏教は、この「火」を消すのが、ゴールなのかもしれない。
なんとなくだが、この「火」は人間が生きようとするものすごいエネルギーで、だからこそ、ここから様々な情動や認識が発生してくる。
これが消えると、おそらくそうした情動や認識も、消える。
生存本能を消すというよりは、生存本能に反応する機能が、消えるというべきか。

これを消してしまうことができれば、なるほど、「生存は潰えた。二度と生まれることはない」と宣言できるような気もする。

ただ、消してしまっていいの?これ。
なんか、消してしまうと、自分として継続できるのか不安になるのだが・・・

初期仏教の時代は、この火が生み出す諸々の情動と認識が、苦しみの一因だった。
きっと、耐え難いほどの。
そして釈迦を始めとしてこの日を消すことに成功した人たちは、もはや同じようにこの火が生み出す情動と認識、それによる物語の世界に生きることはできなくなり、サンガの中で生きるしか無くなったのではあるまいか。
また、それが可能な時代だったのではあるまいか。

正直、そこまでは・・・求めないかも・・・。

現代日本において、肉体的な苦痛は大分減り、むしろ精神的な「悩み」「苦しみ」がメインになった。
特にIT業界に身を置く自分にとっては。
そのための抜苦与楽として仏教に近づいたが、そのゴールとして出家してしまっては、なんというか本末転倒という気もする。

この火を消すところまでは、追い詰められていないし、消すのももったいない気がする。
在家の身として社会のルールの範囲内で現世の快楽を享受するのも、溺れない限りはそう悪いことでも無いだろう。
だから、求めるものとしては初期仏教のゴールとしての涅槃寂静は、若干ズレている。
そこまでは求めていない。
欲しいのは、意味と物語に絡め取られた世界にガッツリ浸りつつも、それでもなお自分の中の火をうまく活かす、そのためのメンタル・コントロールやメンタル・ケアとしての技法とアプローチだ。

長くなったが、悪夢で目が覚めた早朝と、その時の感覚を風呂場で思い返してつらつら思いを重ねたのが、以上となる。

正直自分が感じた「火」が、初期仏教で言うところの、吹き消すべき火であるか確信は無い。
もしかしたら仏教が説くのは別の火で、自分が感じた「火」は仏教であっても吹き消しちゃいけない「火」なのかもしれない。
ただあの「火」を認識した時に、自分は間違いなく「畏れ」を感じた。「この火を消したら、もう戻れない」と。
多分精神のトレーニングを重ねれば消せる気がする。でもそれをしてしまったら、もう戻れない。そんな予感を感じた。
いくら世間でがんじがらめにされる意味や物語から解放されるとしても、そこまでは求めていない。
確かにそう感じたのだ。

全ては自分の中の出来事で客観性もへったくれも無いのだが、それでもなんとなく、仏教の輪郭を捉えつつある。
そんな気がする。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-29 01:27:23
md5:787c149faea5523631024f040370e50a
sha1:911de634eac7247baa588b6b94d76993373d57ff

日記/2019/01/13/ソースコードの内面化  

所有者: msakamoto-sf    作成日: 2019-01-13 22:47:37
カテゴリ:

この歳になってようやく気がついたが、数年に渡りほぼ自分一人でメンテナンスしているソースコードは、自分そのものだ。

自分の内面的な思考が染み付いていて、どこになにがあるか全て把握し、日々の生活(開発作業)が行われる、家であり寝室であり台所であり浴室でありトイレである。

そもそも会社からの帰り道やプライベートタイム、ましてやお風呂に入ってる間に思いついたり練ったアイデアが展開されているのだから、その点からも自分の内面・プライベートがそのまま延長されたテリトリーであり縄張りである。

そのためか、土足で上がってくるようなエンジニアを想定すると自分でも驚くほど攻撃的な感情が湧く。それは「俺の家で勝手に何してやがんだ!」という感情が最も近い。自分のモノであり、また自分そのものでもある家。それを主人に断りもなく勝手に上がり込んでこちらの流儀などお構いなしに散らかすような人間を想定すれば、怒りが湧いても当然といえる。

逆に、「他所様の家に上がらせてもらってる」という謙虚さが感じられる相手であれば許容できる。具体的には、相手の中の常識や流儀で家を使うのではなく、「お宅の流儀を学ばせてください、お宅ではどうやってますか?これはどう使っていいのですか?」と、こちらの流儀を聞いてくるような相手であれば信頼できる。

少なくとも、どうやら自分は、そう感じてしまうタイプらしい。

もちろん、特に仕事で開発しているものであれば、ソースコードは製品であり、自分そのものとして扱うわけにはいかない。
とはいってもなんだかんだの事情と歴史で、できる範囲で「自分色」は薄めてきたつもりではあるものの、フレームワークの手当が薄いとどうしても自分が作ったオレオレ流儀の部分が大きくなってきてしまう。

例えるなら、もともと売家として自分一人で建て始めた家だが、当面は自分一人しか住まないこともあり、自分が住みながら内装や部屋を増改築している間に、どうしても自分にとって居心地がいいように作ってしまったところが多い。

これをチーム開発に適合させるにはどうすればいいか?
自分一人の内面と濃密に結びついた、内面そのもの。これに入ってくるには、新しい人も相当なストレスというか居心地の悪さにさらされる可能性が高い。
扉の開け閉め、便器の蓋の開閉、トイレットペーパーのブランドや交換方法、台所での細かい道具の使い方、お作法、e.t.c...
それら全てに、それまでただ一人の住人であった自分の内面・価値観・判断基準が染み付いていて、まずはそれに従わないと、家に居させてもらえない。
あるいは、自分がその人を受け容れられなくなってしまう。

そうした感覚無く、「俺は私は」で自分の考えを自分の流儀で設計・コーディングしていくようなタイプはどうしても排斥したくなってしまう。

他者の意見は参考にするなり受け入れる方が良い。
だが、同時に家全体のメンテナンスや維持という責任がある。

家全体の設計の統一感・メンテナンスの容易性を実現するために、絶対に守るべきラインがあるし、絶対とは言わないけどなるべく守ってほしいラインがあるし、妥協できるラインもある。

重要なのは、そのラインが今の所、最初の住人であり数年に渡り家を建て増ししてきた自分の頭の中にしかない、ということかもしれない。

文書化するか、あるいはそれこそつきっきりでペアプログラミングするなりして、自分のお作法・判断基準のラインを徹底的に新しい入居者に叩き込むというのもありだろう。

それでも当面は家全体の責任を負うのが自分であれば、自分が100%納得するか、ある程度妥協できるソースコード以外は全てリジェクトする他ない。
作品というのはそういうものだろうし、今の所もっとも内面が反映され作品としての統一感を出しているのが自分であり、またぼちぼちユーザが使っている以上、自分が納得するか、納得の上で妥協するもの以外は出せない。
というか、出してしまうと、作品としての統一感が崩れてしまったり、結局のところ居住者にとってそこが永遠にストレスになってしまう。
そこだけルールが異なるのだ。

ソースコードは、機能を売るものではあるが、同時に開発者にとっては「棲家」だ。

必要なものがどこにあるか、どういうコンセプトで家具は配置されているか、どこにコンセントがあるか、あるいはどこにコンセントがあるように作られているか、天井の高さは、照明は、床の材質は、家具とのこすれは考えられているか、e.t.c...

これを整えようとすれば整えるほど、整えた人の内面や価値観、判断基準が色濃く生活空間に染み付いてしまう。
避けようが無いのかもしれない。
そのかわり、うまくマッチすれば居住者=開発者のパフォーマンスを最大限引き出すことができる。

とはいえ、全てが「オレ流儀」というわけでもない。
フレームワークを使っていればフレームワークの、ライブラリを使っていればライブラリの、あるいは使っている言語で一般的なスタイルの、それぞれの流儀がお互いに主張する。
それをうまくコーディネートするのも開発者の腕の見せどころだろう。
そういった外部が推奨する流儀やスタイルは、いわば「モジュール化」だ。
ある程度一般化されており、他の人も容易に馴染むことができる。
見慣れた玄関、見慣れた照明スイッチ、見慣れた便器、見慣れた水道蛇口、見慣れたガスコンロ。
別にその家の主に確認を取るまでもなく、自分の経験で問題なく使えるし、主もそれを許容している。だって主も同じように使ってるのだから。

例えば、フレームワーク/ライブラリ/言語のお作法が 3 割で、残りが「オレ流儀」のクラス設計や命名規則などになってたとしよう。
そうなると、他の人が違和感なく作業できる領域が3割で、ほかは逐一、「オレ」にお伺いを立てて「この場合どうしてますか?」と聞かないと、「オレ」は機嫌を損ねてそいつを追い出そうとしてしまう。「オレのやり方を聞かずに、何勝手に自分で使おうとしてるんだ」と。

この状態ではチーム開発は覚束ない。
いくつか解決方法はあると思うが、個人的に挑戦するなら、フレームワーク/ライブラリ/言語のお作法を7割、いや8割程度まで高めて、残りを「オレ」の、流儀ではなくアイデアだけに絞り込む。

つまり「お作法」や「流儀」は可能な限り一般化されたモジュールを使うことにして、本当にコアの思考や言語化し辛い設計の勘所だけを属人性の塊として残す。
実際は「フレームワーク/ライブラリ/言語」が5割、「DDD/関数型プログラミング」などのパラダイム・哲学が3割、「コーディングスタイル・命名規則」が1割で、ここまでが全て一般的に受け容れられているものにして、「オレ流儀」じゃなくて「オレの思考」を残り1割に絞る。

こうすれば、他の人(= 新しい入居者)は「オレ」のお伺いを立てる気苦労がずっと減り、一般化されて学ぶ価値のあるフレームワークやライブラリ/言語/プログラミングパラダイム/コーディングスタイルなどを勉強してすばやく馴染むことができる。

そうなれば、家の増改築は「オレ」一人の仕事ではなくなり、近しいスタイルで力になってくれる戦力が増えるだろう。

気をつけなければならないのが、「オレの常識」を振りかざすのは良くないが、かといって作品等しての統一感を崩すのはもっと良くない、ということ。中長期的なメンテナンスビリティに影響が出てしまう。

理由を示すのが重要だろう。なぜ今はこんな「オレの常識」に従う必要があるのか。それは長期的にどう変わっていくのか。なぜ理不尽で不合理な「オレの常識」に従う必要があるのか。

それはひとえに、自分が売り物としての家のコンセプト・全体設計・品質に責任を負う以上、自分が納得できないものは絶対に入れられない。そうである以上、今は自分のこれまでの判断基準の積み重ねとしての「お作法」「流儀」を学び、まずはそれを真似ることに徹してほしい。
徐々に「オレ独自」の色を削っていく。そうすることで、お互いに納得度の高い仕事をできるようになる・・・多分・・・そうなるといいなぁ・・・。

このようなことをつらつら考えるに、やはり息の長いアプリケーションでは、ある程度大きなフレームワークの方が良いかもしれない。
フレームワークが小さいと、不足部分を手作りすることになり、そこで初期開発者の内面が色濃く出てしまう。
そうではなく、大きめのフレームワークを選択して、初期からフレームワークの流儀にうまく従うことで、初期開発者の内面の色付けを押さえて、入りやすいものにできるのかもしれない。

とはいっても、大きいフレームワークって結局そのフレームワークの開発者たちのお作法や流儀の塊なので、それを学んで適切に使いこなすのがまた一苦労なのだけれど・・・。

そんなことをつらつら風呂に入りながら考えていた。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-13 23:28:45
md5:6fe4e5542032f16f2b2542206d0d244d
sha1:ddbb2acc675befa77c834cc9e89c8dfb56b107a1

Java/JREをバンドルしたJavaのパッケージング、あるいはインストーラの作成(2019-01時点参考URLメモ)  

所有者: msakamoto-sf    作成日: 2019-01-12 20:37:42
カテゴリ: Java 

背景:

  • Java11でpublic JREが無くなる。このため、JREをインストールしておいてもらえば、あとは実行可能jarファイル渡してダブルクリックするだけでOS側の拡張子連携によりJavaプロセス起動、という方式が採用しづらくなる。
    • public JREが無いということは、OS側に拡張子 .jar をjavaコマンドで実行する連携設定をインストーラ一発で入れられないということ、と理解して上の文章を書いてる。
    • 参考 : Java 11ではPublic JREが本当になくなりました - AOEの日記
  • JDK8までは javapackager というコマンドで、Inno Setup などサードパーティ製のインストーラ生成ツールと連携し、JREバンドルしたパッケージングが可能だった(っぽい)。
  • Java11から、JREバンドルして、exeか何かダブルクリックするだけで実行できる配布方式どうすりゃええねん・・・。

この辺の、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が必要っぽいのでそのあたりの差異も試してみたい。

以上。



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-12 20:38:02
md5:f53106e41c8f4d192e2e28142bc40720
sha1:9c4250dc422b27efc23da248692cd65bac6f0a39

日記/2019/01/12/"HTTPS" Proxy (クライアントとプロキシの間もSSL使うタイプ)  

所有者: msakamoto-sf    作成日: 2019-01-12 19:02:02
カテゴリ: HTTP Proxy SSL/TLS 

昔からの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拡張フィールドに含まれるため、盗聴されていればどこに接続しようとしているのか、までは見えてしまう。

以上、メモ。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-12 19:18:57
md5:084bc75cb01979ff141ab43c828abef7
sha1:700531ad45fdcc4b6f1078dc98b6483ebc4967f3

Java/diff(差分検出アルゴリズム)のJava実装調査メモ  

所有者: msakamoto-sf    作成日: 2019-01-06 14:37:50
カテゴリ: Java 
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-06 14:38:22
md5:6e9bf1171e05162403329ba4e00ff721
sha1:f484bc02353c4635299ab4520cfff3ec17afe69a

Java/Markdown処理系, asciidoc処理系のURLメモ  

所有者: msakamoto-sf    作成日: 2019-01-05 14:08:21
カテゴリ: Java MarkDown 

Java実装のMarkdownパーサライブラリのURLメモ。

Markdownの仕様 : 2018年にもなると、CommonMark と GFM (Github Flavourd Markdown) がメジャー?

Java実装ライブラリ:

Markdownではないが、Asciidoctorも良さげ。



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-05 14:09:04
md5:82ccd9e22243bcb9dda6f89cd437846c
sha1:9895cc67f7cc51c2d0a6af6e18ec5e0748dfe8ec