目次 コードを書く人間なら、キーボードにこだわりたくなるものだ。ノートPCをメインにしている場合はキーボードを変えることは難しいが、それでもJIS配列かUS配列など一度は考えたことがあるはずだ。 このサイトで何度も書いている通り、プログラミングのほとんどは試行錯誤の繰り返しで作り上げていくものなので、試行回数とその試行までの時間をいかに短くできるかが重要なってくる。つまりコンピュータの操作の速さってプログラマの腕に直結するってこと。（この記事を参照） そして我々エンジニアにとってのコンピューター操作のメインインターフェイスはもちろんキーボードなのだ！ 我々はトラックパッド4本指シュッってやってるのをドヤってる輩を全力で軽蔑する人種であるべきなのだ。トラックパッド上で指5本をくぱぁとかやってる奴はすぐに立ち去れ。 US配列なんかかっこよくね？ キーボードを選ぶ基準はたくさんあるけど、まずはUS配列かJIS配列かを選定した方がいい。そして私はUS配列を強くおすすめする。（UK配列とかその他の配列は考慮外だ）

さて、NYMというプロジェクトをご存じだろうか？2022年4月現在、おそらくほぼすべてのインフラエンジニアやネットワークエンジニアがNYMを知らないだろう。一方で仮想通貨トレーダでこのページたどり着いたひともいるだろう。この記事ではNYMへの投資のお話は一切しないのでご注意いただきたい。エンジニア目線でのプライベートネットワークについてあれこれ考察してみたいというのが目的である。 NYMとは NYMとは以下のプロジェクトのことだ。 https://nymtech.net/ 詳しい解説は公式の動画等を参考にしてもらいたいが、平たく言うと、通信の秘匿性を高めるネットワークを提供するプロジェクトのことらしい。 近年ではWebリクエストはHTTPS(SSL)通信が一般的で、“暗号化"されているといわれる。確かにそれは事実だが、エンジニアの諸君はご存じだと思うが、IPHeaderやトランスポートヘッダーなど"暗号化"されていない部分がある。これは、例えばあなたが入力し送信するクレジットカード情報はしっかり暗号化されているが、あなたの家のグローバルIPアドレスと送信先のIPアドレスやポートなどは見えてしまうってことだ。当然、ハッカーや、国家権力、巨大企業でないと、そもそも特定の通信を傍受することは難しいかもしれない。しかし、例えばあなたが如何わしいエロサイトを見ていたとして、国家権力などがそのエロサイトのサーバーをおさえて調べれば当然、あなたが見たということも突き止められるはずだ。(IPアドレス開示で特定される) VPNやTorではだめか？ NYMのサイトでは、VPNやTorとNymを比較している。 VPNはどこかのVPNサーバーやVPN事業者を介して通信する方法だが、VPNサーバーにはあなたが接続した形跡が残ってしまう。そしてVPN事業者がその情報を外に漏らすならまったく秘匿性がなくなってしまう。また、Torも同じで、Proxyサーバが本当にあなたの秘匿性を確保してくれるかどうかは疑わしい。むしろTorは匿名の存在が無償でネットワークを構築しているらしいので、その中に悪徳な人間がいたり、国家権力がTorネットワークを傍受している可能性がある。 そこでNYMでは、ネットワークのノード提供者にNymトークンの報酬を与え、さらに通信パケットをばらばらにしてMixnetを通す技術によりプライバシー通信を実現しているらしい

2020年ごろから巷で「web3.0」みたいな言葉が流行っている。また、もっと前から仮想通貨のブームもあり、システム業界ももしかしたらどんどんと「分散型」のweb3の時代に突入していくのかもしれない。 私は仮想通貨なんかを少し嗜む程度でweb3の世界のDAOなどのシステムを構築した経験はない。なので完全な素人なのだが、今回簡単にweb3を体験してみたのでこの情報をシェアする。もしかすると5年後くらいにはweb3の掲げるDAO(Decentralized Autonomous Organization)が一般化しているのかもしれないし、今のうちにちょっとかじっておこうと思う。 完全分散型なWebサイト構成 今回の構成は以下で行う。 ENS(Ethereum Name Service) Fleek(IPFS) ENSの購入や設定にETH(イーサリアム)が必要なので、完全に無料ではできない。また、以下はすべてイーサが入ったウォレットと接続している前提だ。 DNSではなくENS 従来のシステム業界ではDNSという言葉が存在するが、このWeb3の世界ではENS(Ethereum Name Service)が最も有名だ。

ブラウザ上でカメラを起動して映っている映像を操作することができる。そして映しているものがあらかじめ用意されたどの画像と一致するのかというシステムを作成した。よいライブラリが存在しないか探してみたんだが見当たらなかったので、自分用に作成したものを公開してみた。正直汎用性はないけど参考にしてみて。(Rust,Node必須) https://github.com/j7w2/image-scanner 全体的な仕様 カメラの起動、映像の判定などすべてブラウザ上で動作させ、バックエンドなどとは一切通信しない。 QRコードを撮影するように特定の形の対象をカメラにおさめるので機械学習での物体検知や画像の解析は行わない 画像が同一か否かについては"Perseptual Hash (pHash)“で判定 hash化の処理に多少の時間がかかるのでRustのwasm(WebAssembly)を作成してJSから呼び出す pHash値の距離で画像判定 画像が近似しているかどうかの判定ロジックで手軽なものに画像のhash値の距離で測定するpHashという方法がある。今回これをを使用するが、手軽といっても画像のピクセル値をハッシュ値計算するのは結構なマシンパワーを使用するようだ。なので処理効率が良さそうなRustで画像ハッシュ化するモジュールを作成し、WasmとしてJsから読み込む形をとる。 RustでgRPCが最速か？1msを追い求める 目次 リクエストからレスポンスまでの時間はなるだけ短いほうがいい。ユーザー操作性的にも好ましいし、昨今ではリクエスト～レスポンスまでの時 … Read More また500px~1000px程度の画像のハッシュ値での精度が、最も高そうなのは(12bit×12bit)程度だったのでデフォルトでhash_sizeは12とした。

AWSのALB(Application Load Balancer)を使って、HTTPS強制や、wwwありなし強制のリダイレクトを行うと思われる。その場合特に難しいことはなくそのための情報も腐るほど出てくる。ALBは料金も少し安いし通常はこのALBを使用すると思われる。 ALBが使えないケース(Route53が使えない) しかし、ALBを使用できないケースもある。それは、NS（ネームサーバー）をRoute53に設定できない時だ。Route53以外でDNSを設定する場合、ALBへのルーティングはCNAMEを設定せざるを得ない。しかし、例えば、WEBサーバーをドメインaaa.comとwww.aaa.comで運用したい場合（wwwなしをwwwありにリライトして）、「aaa.com」はCNAMEを設定できないのだ。DNSの仕組み上不可能である。そのため、独自ドメイン(aaa.com)をALBへ向けることができないのだ。（自分が知らないだけで、外部NSでALBを運用する方法があるのかもしれないが） こういう場合は、NLB(Network Load Balancer)を利用すれば、リダイレクトを実現することができる。このNLBの情報があまり引っかからないので紹介する。ちなみに今回は「wwwありSSL通信」へリダイレクトするケースを紹介する。 NLB、NginxでSSL通信 NLBでは、 ロードバランサに対してStaticIPアドレスを設定できる。そのため、DNSにwwwなしもwwwありもAレコードで設定できNLBに向けることができる。しかもAWSのACMによってSSL証明書をセットしてhttps通信も簡単にできる。以下のイメージだ。 そして、Webサーバー側は80ポートで受けるので、ロードバランサではなくNginxでHTTP通信をHTTPS通信へリダイレクトするはずだ。ググると以下のconf設定がよく出てくる。 if ($http_x_forwarded_proto != https){ return 301 https://$host$request_uri; } しかし、これはALB用の書き方で、NLBではうまくできない！！

目次 リクエストからレスポンスまでの時間はなるだけ短いほうがいい。ユーザー操作性的にも好ましいし、昨今ではリクエスト～レスポンスまでの時間で課金されるクラウドサービスも多い（GCPのCloudRunとか）。特にマイクロサービス設計の場合は、リクエスト～レスポンスまでの時間がより重要になってくる。 今回はプログラミング言語や通信プロトコルによってどのくらい時間が変わるのかを紹介。このような記事は量産されてきているだろうけど、その量産に加わることにする。なお以下検証は、普通にググって出てくるような実装方法で行っているので、最速最適化を行ったプログラムコードではないことをご了承いただきたい。 みんなの280時間を奪ってはいないか？ ものすごい単純計算なんだけど、10,000人のユーザーが存在していて、年間で1人あたり1000回コールするサービスがあるとするじゃん？もし、そのWebAPIのレスポンスまでの時間を100ms（ミリ秒）短縮できると、全部でおよそ280時間もの短縮になるんだよね。 逆に言うと、よろしくないプログラムコードを書いたり通信方法の選択によって、 みんなから280時間も時間を奪っているかもしれない。しかもそのうち無駄なコンピュータ処理時間もかかっているため、コストも上がる。もちろんユーザーの通信状態によってレスポンス時間が大きく変わるのは間違いないが、今回は、プログラム言語(プログラムの実行時間)と通信プロトコル(リクエスト・レスポンスの通信時間)のみにフォーカスする。またAPIの実行環境はGCPのCloudRun（1cpu 512MB）とする。

今回のような検証は多分何十年も前からいろんな人にやり倒されてきたことかと思うが、ここであえて書いてみる。今回はプログラミングは無関係だ。ていうかPythonも無関係だ。 自分は10年ちょいくらい前にFXで多額のお金を溶かしてしまった人間だ。と言っても数百万円程度だが、若かりし自分にとっては首吊りレベルに落ち込んだ。あれから月日はたったが、あのときのトラウマからFXで勝つことは不可能とさえ思っている。以下のような記事で、AIでFXの取引を行うという検証を行っているところだが、投資金額はものすごく少なくしている。 AIでFXのトレード判定実装したらゼニの匂いがしてきた 前回の記事でFX（為替）のレートと速報ニュースの関係についてデータを調査してみたが、今回は速報ニュースを受けたらすぐに機械学習（AI）のNLPモデルで分類し … Read More いろんな情報を収集したり、テクニカル分析を駆使して自信満々にポジションを持って、朝起きたら給料数か月分が吹き飛んでてオハギャーみたいなのは二度と経験したくないんものだ。以下の内容は、トレーダー達は誰でも知っていることだろうけど、無知な私が気付いたことを書きたい。 な～んにも考えずに無心でランダム取引の場合 ポジションをいつ持つか、LかSかなどの判断が間違えているのか原因は定かではないが、ひとまず何も考えずにコイントスで ランダムに意思決定する場合 を考えてみる。そして膨大な試行回数で一体どのくらいの期待値になるのかを調査してみる。

目次 前回の記事で書いたとおり、全くユーザーが動作させる機能がないようなコーポレートサイトやLPサイトは静的サイトで作成するほうが、あらゆる面でメリットがある。ところがそれら以外の普通のWEBシステムでは、バックエンドでの動的な処理が必要なはずだ。今回はそのセキュリティの話。 バックエンドのアクセス制御・セキュリティ対策 今回考えたいのは以下のようなことだ。これは静的サイトだけでなく普通のSSRサイト(.NetとかRailsとかlaravelで作ったシステム)でも起こりうることだ。ちなみにクライアントはブラウザやアプリのことを意味する。 つまり、特定のクライアント以外からAPIを悪い人がたたきまくれる状態って非常に怖いよねってこと。ある程度対策が存在するけど、特に静的サイトではこういう対策がお粗末なサイトがたくさん存在する。 これはCORS, CSRFなどの話か、、否！ まず、適切なユーザー認証を行うこと、そしてCORSの許可ドメインをガバガバにしない、CSRFトークンを送信するなどの対策は当たり前にやってほしい。CORSとかCSRF、XSSなどでググるとSSRサイト、SPAサイトそれぞれの対策方法が出てくるので、よくわからない人はチェック。

WebAssembly（wasm）が世の中に登場して久しいが、今回はこのWasmのDecompile（逆コンパイル）の話。 聞くところによるとWasmは、不正にマルウェアの稼働など悪用に使われていることが多いのだとか。またwasmはJavascriptに比べてマシンパワーを効率的に使うことができるタスクがいくつかあるが、2022年現在では未だブラウザ内のほとんどのDOM操作、UI操作がJSの処理速度に劣っているとも言われているので、結局将来的にwasmも消えていく可能性もある。 WebAssembly(wasm)にセキュリティ情報を含めて良いか コンパイル後のwasmファイルはバイナリデータであるが、当然デコンパイルして人間が理解できそうなコードに戻すことができる。なので、重要なシークレットキー的なものをwasmの中に入れてしまうと抜き出されてしまう可能性がある。なので、結論から言うと 重要な情報（dbの接続情報、他のサービスへのシークレットキーなど）は絶対にwasmに含めてはいけない。 一方、別に抜き取られてもそれだけで何か被害があるわけではなく、できれば知られたくないような情報ってこのwasmに隠せないかなと思ったわけ。例えば認証無しでコールできる公開APIの接続キーとか。もちろんブラウザのインスペクターでNetworkを見ると接続時のキーなどは見えてしまうけど、wasmでワンタイムトークンを発行しさらに暗号化したものをHTTPヘッダーに付与して送信するとかにしたらどうだろう？APIへの接続キーを自由に生成するにはwasmを逆コンパイルして中身を解析しないと分からず、このコストが高ければ高いほどハッカーはあきらめてくれる可能性が高い。 ということで今回はRustによるWebAssembly(wasm)のデコンパイルと文字列の難読化について調査してみた。 Rustでのwasmのコード 今回は以下のコードでwasmをコンパイルして使ってみる。 externcratewasm_bindgen;usewasm_bindgen::prelude::*;#[wasm_bindgen]pubfn secret(key: &str )-> String {ifkey!="this is pass!"{returnString::from("error");}returnString::from("success")} バ

目次 WEBサイトって一般的にブラウザがHTMLやCSS、Js、その他画像などのファイルを読み込んで描写されているものを言うよね？一方Webサイトを作成するには、Webサーバーが必要という。特に有名なCMSであるWordPressではサーバーでPHPやデータベースが動作してサイトが構築される仕組みになっている。私が学生のとき、WEBサイトはHTMLやCSS,JSによって表示されているのに、なんでサーバーサイドの言語（PHPなど）とかDBが必要なのかなと思ったことがある。 当然PHPとかDBは動的な挙動をするために必要なわけだ。例えばブログのコメント機能とかログイン認証機能とかのためにサーバーサイドのプログラムが必要だということだ。ただ、世の中の多くのサイトやブログにサーバーサイドの処理が必要かって言われると、はっきり言って不要じゃないかと思う。たとえば多くの小さな会社のコーポレートサイトはWPで作成されていることが多いけど、 わざわざWPで作成する必要ある？ サーバーでPHPが動いたりMySQLに接続してデータの読み書きが頻繁に行われたり、まるで無駄な動作が多い。 ワードプレス使う必要あるか？ 例えば3ページしかないコーポレートサイトで、ユーザーが操作する機能（コメントなど）がないサイトを考えてみよう。トップページとAboutUsページとかプライバシーポリシーとかのページのみで文字列と画像で構成される。こういうサイトは静的サイトと呼ばれる。本来ならサーバーサイドでプログラムが動作する必要はないしデータベースも必要ない。

ここ2年ほど スミッシング詐欺(=SMSフィッシング) のメッセージを何通か受けたことはないだろうか？Amazonとか銀行からSMSのメッセージが届き、そこにURLが書かれていてタップすると詐欺サイトに飛ばされるあれのことだ。まぁ普通に若い人はあんなバカな詐欺に引っかかるとは思えないけど、飛んでくること自体にイラついたりする。なぜ電話番号を知っているのか？って思うかもしれないが、なんでも、犯罪者はランダム（または連番で大量）でSMSを送信しているらしいから、たまたまあなたの携帯に届いてしまっているってことだ。 今回この詐欺師達の手口を分析して、反撃手段を考えてみたい。ジョーダン半分で楽しんでもらいたい。 実際に届いた詐欺SMS URLを見てみて。“https:abnrno.com"って。いや、どこかに"amazon"くらい入れろよってくらいやる気なし。でもお年寄りとかはURLなんて見ずにポチるからどうでもいいんだろうね。そしてこのURLをタップした先が以下だ。 amazonのログイン画面やん！これにあなたの本当のamazonのアカウントを入力したら、個人情報が抜き取られるっていう詐欺ね。実際の本物のAmazonのログイン画面は以下で、見た目は少し違っている。 詐欺師に関する情報はどこかに書かれているか？ WHOISコマンドで見ても、所有者の情報は全く分からないようだ。分かるのはnamesilo.comというサービスで取得されているドメインってことくらい。 dig打ったら以下の情報が出た。 abnrno.com. 0 IN A 172.

すべてのプログラマを上級者に導くサイト！最短距離で一人前のプログラマになるためのノウハウを公開します！

すべてのプログラマを上級者に導くサイト！最短距離で一人前のプログラマになるためのノウハウを公開します！

すべてのプログラマを上級者に導くサイト！最短距離で一人前のプログラマになるためのノウハウを公開します！

すべてのプログラマを上級者に導くサイト！最短距離で一人前のプログラマになるためのノウハウを公開します！

すべてのプログラマを上級者に導くサイト！最短距離で一人前のプログラマになるためのノウハウを公開します！

すべてのプログラマを上級者に導くサイト！最短距離で一人前のプログラマになるためのノウハウを公開します！

すべてのプログラマを上級者に導くサイト！最短距離で一人前のプログラマになるためのノウハウを公開します！

すべてのプログラマを上級者に導くサイト！最短距離で一人前のプログラマになるためのノウハウを公開します！

すべてのプログラマを上級者に導くサイト！最短距離で一人前のプログラマになるためのノウハウを公開します！