へっぽこびんぼう野郎のnewbie日記

けろけーろ(´・ω・`)! #vZkt8fc6J

技術書典5の全サークルの頒布物のリストを勝手につくりました

1サークルごとにクリックするのがめんどくさかったので、公式サイトのAPIを勝手に使って、適当にtableタグで囲いました。

本来なら画像はそのままダウンロードするべきではないかもしれませんが、負荷をかけるとよくないと思い、保存してあります。言ってもらえれば削除いたします。

2018/10/05 21:00 時点でのものです。なので当時まだサイトを変更していない人のものは無いと思います。

更新はするかどうかわかりません。

↓こんな感じで出ます

f:id:haruharu1:20181005220538p:plain

↓ ダウンロード先です。

[削除しました]

追記:

2018/10/07 23:45に取得したデータで再度作成しました。

[削除しました]

or

[削除しました]

適当に解凍して開いてください。

追記:

終わったので削除しました。

1分以内で作業が終了する米の炊き方 〜「線で計るのとかめんどくさい」とか言っちゃうズボラな人におくる炊飯器での米の炊き方〜

米を何合か確認して、その後水を線まで入れるのってめんどくさくないですか??

ぼくはそれがめんどくさいので、線は使ってません。

まず米と水の比率って、大体米1に対して水1〜1.2であればいいらしいです。体積の話です(白米の場合。それ以外はしらない)

なので米が200mlだったら、水は200ml〜240mlにすればいいわけです。

ぼくは、米をすくうための計量カップを使って米をすくい、まぁだいたいこれで1杯だなと思ったらそのまま炊飯釜に入れてます。

多く炊きたいときはさらにもう1回すくっています。

そのまま米をふつうに手で釜の中で研ぎます。じゃぶじゃぶ。最近のはそんなに研がなくていいはずなので、ぼくは1回研いだら終わりにしてます。

そして釜の中の研いだあとの水をジャーッとシンクに流します。もちろん米が流れていかない程度にながします。全部の水を流さず、ある程度流れたらあとは適当でいいです。

その後、水を、さっき米をすくった計量カップ1杯入れます。さっき2杯米をいれた場合は水も2杯3杯米を入れたなら3杯というふうに入れます。

そのまま釜を炊飯器に入れてボタンを押します。使った計量カップは洗ったのを乾かすところにでも置いておきます。

 ↓

_人人人人人人人人人人人人人_
> ふっくらできあがり!! <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^ ̄

解説

研いだ後、水をジャーッと適当にシンクに流しているのは「多少残ってもそんなにおいしさに影響がないから」です。

その後は、米1に対し、水1.2をこえないようにしたいけど、水1は超えさせたいので、水1くらい(1杯)を釜に入れています。

そうすると研いだ後の余った水と合わさりいい感じになります。

シンクに流すときにしっかり水を切った場合は、水1より気持ち多めに入れます。あまりにもてっきとーに水を切っていて、めっちゃ残っとるがなって感じたのなら水1弱ぐらいを入れます。

米を2杯分炊くときは、もっと雑に水を入れても問題ないと思います。

ぼくがこのやり方で失敗したのは、最初にやり方を思いついた1回だけです。その後5年ぐらい炊いてますが、一度も失敗していません。

最初の1回の失敗は、水を1.2弱入れたらふにゃふにゃになったやつです。研ぎ汁の残りのことを忘れてたので、水が1.2よりも多く入ってしまっていました。その最初の入れすぎたことを後悔してからは、水1にしてます。

それ以来、毎回固くもなくやわらかすぎず、おいしくたけています。

味にうるさい人は水の量を毎回微調整してみてください。微調整の際には二分探索がオススメです。

水や米の量が雑でもいい理由は

計量カップの底面積の方が、釜の底面積よりはるかに小さいので、計量カップで線の位置が5cmずれても、釜の1cmのズレよりも小さいからです。 *1

ちなみに高さ5cmというのは約1杯分なので、計量カップだとそんなにズレることはありえないです。

まぁそんなわけで、釜の線での1mmのズレと戦うより、計量カップでの5mmと戦った方が楽なのは確定的に明らかです。また、釜の目盛りを斜め上から見ると、余計にミスりやすいです。なのでたまに失敗することがあるのだと思います。わざわざ水平にして目をこらしたりすると、それだけ時間を食います。

つまりぼくのやり方だと、5倍適当でもいいわけです。だから早く終わります。

↓これぐらい違います。(この黒い線の中に水の表面をもってこなければいけないと考えると、上の方の線はつらいことがわかります)



↓こっちはもう1つの例



メリット

とにかく作業がはやくおわります。

釜の中の線で計ると、線に水がくるまでどのくらい入れればいいのかわからなくなって、水をちょっとずつ入れて「もうちょっと」「入れすぎた」「水捨てよ」「もうちょっと」のような作業をすることが多いと思います。米を炊くときに一番時間を食うのがこれなので、カップで水の量を計ることで(しかも目盛りを特に見ないし)ものすごい時間短縮されます。

早すぎるので↓みたいな感じで対応されることもあります。

X「ごはんたいてよ」

ぼく「おっけー」

米すくう(10秒) → 米とぐ(20秒) → 水流す(10秒) → 水入れる(10秒) → ピッ(5秒)

ぼく「〜〜♪ ゲームの続きしよ♪」

X「あれ、なんでゲームしてるの?米たくっていったのに……」

ぼく「たいたよ」

X「うそつき。そんなに早く終わるわけないじゃん。終わってるだとッ!!?」

X「ちゃんと研いだ?」

ぼく「研いだよ」

X「線で計った?」

ぼく「はかってないよ。カップでやったから」

X「うわ絶対失敗するやつじゃん。最悪だ」

ぼく「だいじょうぶなのに……」

〜40分後〜

X「なんでちゃんと炊けてるの……しかもおいしいし……」

最高にドヤ顔できます。わけのわからない特殊能力持ちだと思われます。おためしあれ。

あと、当然ですが別に計量カップでなくてもできます。

茶碗とか紙コップとかお玉とかでもできるので、キャンプに行ったときに「計量カップ忘れた…」とかなっても紙コップで計って炊くことでヒーローになれます(なったことないけど)

個人的に、日本全体でこれが普通じゃないのがおかしいと思います。炊飯器の発明という文明の進歩によって、米の炊き方について日本人全体が退化したように感じられます。

手順まとめ

米を計量カップでX杯すくって釜に入れる
 ↓
米をとぐ
 ↓
研いだあと水を捨てる
 ↓
米をすくったときの計量カップで、水をX杯すくって釜に入れる
 ↓
炊飯器に釜をセットして炊飯ボタンを押す
 ↓
炊けるまでまつ
 ↓
いぇいいぇいいぇあ♪

楽だし簡単だし早く終わるしおいしく炊けるのでマジでオススメです。あ、もちろん、炊けたあとはむらしてください。

免責

このやり方でもし仮に失敗したとしても「米返せ」などということに応じることはできません。

たとえば「キャンプ行ってドヤ顔でおまえの言う通りやったら、米カチコチになって赤っ恥かいたやんけ!」って文句を言われても「わろた」って返します。ご注意ください。

では楽しい炊飯ライフを!

*1:厳密には「底面積」ではないけど、こまけぇこたぁいいんだよ。5倍という数値も特に根拠はない。雰囲気5倍っぽいから

JavaやPHPのハッカソンに潜り込んでPythonにリプレイスしてきた話

先日忍び込んだハッカソンで、「Java+Spring Frameworkで書かれたこのサンプルコードか、PHP+Laravelで書かれたこのサンプルコードを参考に何かつくってください」というお題をもらったので、朝から夕方まで7時間弱で食事は水オンリーで作業した結果、Python+Djangoでリプレイス作業をしたという成果をだして、気づいたことがあったのでとりあえずブログに書きます。成果はGitHubにあがってますが、汚いので見ないでほしいです。あとそのままでは動きません。pipで必要そうなライブラリをインストールしてください。

書く前の知識

  • Javaは書いたことある
  • Tomcatは知っている
  • SpringBoot自体は実行したことは1回ある
  • PHPは知らない
  • Spring Framework何も知らない
  • pom.xmlとはなんなのか
  • LTIやCaliperというIMC Globalという団体が作ってる規格がよくわからない(そもそもこれがメイン)

得られた知識

Java関係のもの

  • pom.xmlは、NPMでいうpackage.jsonみたいなもん
  • Spring Frameworkの中にはTomcatがあるものもある
  • DI使われていて便利そうだった。ただServiceの使われ方が何かおかしいように感じた
  • Javaはやっぱり冗長だった。Modelのところにgetなんたらとかが大量にあって悲しく感じた
  • RepositoryでのCrudRepositoryは便利そうな感じがしたけど、Djangoの文化と違いすぎてやるならフレームワークを作るところからやる必要を感じた
  • Spring Bootでのエントリーポイントが、PythonでいうWSGIみたいな感じで萌えポイントだった
  • SpringのControllerで、アノテーションにRequestMappingがあるのはいいなと思った(いまさら感)
  • IntelliJは良い

PHP関係のもの

  • 引き続き知らない

JavaPHP関係以外で得られた知識

  • LTIは要はHTTPのセッションに何入れるかのやつ。それとOAuth2
  • CaliperはCaliper(日本人はみんなそんなに知らないということがわかった)

パワーコードの教訓として得られたもの

パワーコードは実践では良くない

Spring Frameworkのことを全然知らないままやったので、何がどうなっているかわからないまま書き始めていた。

それで「とりあえず」と最初に決めたことにあとあとまで引きずられてしまった。たとえば最初はHello Worldからやったんだけど、そのHello Worldの書き方を最後まで継承し、コピペでいとも簡単に増殖した。

わからない→わかった!→じゃあこの書き方まずいよね→まぁいいか

というスパイラルが繰り返された結果、負債につぐ負債が誕生した。

たとえばViewを書くときに、最初はHello Worldからやったので、View(DjangoのView。Spring FrameworkではController)はクラスから作らず、関数で書いていた。↓こんなの

def index(request):
    return HttpResponse("Hello World")

ここにロジックを追加(個人的にロジックはここに集約すべきではないと思うけど)して、あとからテンプレートを追加することになったので、とりあえずテンプレートにコンテキストを渡せるものを作成することにした。

このへんで、サンプルのJavaコードで使われている「model」には、Djangoで使われているコンテキストの役割もあるということが明確に判明した。

それと同時に、ThymeleafというSpring Frameworkの中で使われるテンプレートがあることを知った。書き方はunderscoreやJinja2とは違って、どっちかって言うとWPFxamlみたいな感じ。

def my_render(template_file, modellike):
    template = Template('<html>foo</html>')
    html = template.render(Context({}))
    return html

def index(request):
    # ~~~ ロジック ~~~
    return my_render("index.html", model)

この状態から、ファイルからロードしてレンダリングする場合に、テンプレートの文字列をいちいちロードするのがめんどくさいので、ファイルをその場でオープンするという荒業を使っていた。

def my_render(template_file, modellike):
    source = open('app/templates' + template_file).read()
    template = Template(source)
    html = template.render(Context(modellike))
    return html

def index(request):
    # ~~~ ロジック ~~~
    return my_render("index.html", model)

そして、ここのindex関数部分がコピペでどんどん増えていく。

最初からDjangoで用意されていたものを使えばいいという話だけど、そもそもわかってない状態から作り始めてこの時点で「こういうふうに書くのがSpring Web MVC Frameworkというやつらしい」ということを理解したので、最初からそういうふうに作ることは知識的に無理だった。

なので、こんな感じでどんどん最初のものから負債が溜まっていく。0.1の瑕疵が最終的に全てを食い尽くすモンスターになっていった。

そのため、初期ではわずかしか行わなかったデバッグ作業も、終盤では多く含まれていた。つらい。

他人が書いたいいところを活かせず、自分の領域にすべて持ち込んでしまう

Spring FrameworkにはどうやらDIがあるというのを知ったけど、これを時間内に実装するのは無理だと判断して無視して実装していった結果、Pythonの方で冗長になり、何の生産性もないクラスがいくつかできあがってしまった。

逆に明確にDIを理解していないことが判明したことはよかった。

いわゆる抽象的な概念の知識が増えない

時間に追われていることもあって、既知の知識の範囲内でコーディングすることしかできなかった。

新しい難しい概念で腰を落ち着かせて考えるべきものは、こういうコードの書き方では手に入れられないなと思った。

今回得られた知識は、最初からある程度知っていた知識を焼き直したぐらいのものだった。

そういう面から見ると、業務とは直接関係ない勉強というのは重要だと思った。

時間管理は重要だった

「これは絶対無理。これはいける。これはできるけど時間的にキツいし、なくてもいいから切り捨て」という判断がだいじだった。

「この領域は何分でできるか。1個で5分なら、5個で完成だから15分くらいかな?」「残タスクはどれだけかマークダウンで洗い出し」というように見積もって、時計をときおり見ながらタスクをこなしていった。

タスクの洗い出しは、各領域を整頓するために脳からシリアライズしたぐらいで、途中で完全に全体構造が見えてからは全く必要なり、バージョン14時ぐらいで更新停止した。

ものすごく疲れる

タスクが完了してから、空腹と頭痛と体のだるさを一気に感じて死にそうだった。

帰りの電車で座れなくて「アアアアア」とゾンビみたいになっていた。

たぶんいつもやってる仕事よりやや簡単だったのでゾーンに入っていたのだと思っている。

時間管理の結果「飯を食う時間は無駄」と判断して休憩なしでやっていたので、こういう作業の仕方ばっかりやってると体を壊しそう。

ライブラリを読むのは正義

他人が書いたライブラリの中でエラーが発生したときは、まず読み、意味がわからなかったらググり、エラーの意味がわかるけどなんで出ているのかわからない場合、ライブラリの中でデバッグするという挑戦が必要だと思った。

それで仕様がわかったりしてた。(ちなみにハッカソンではあと5分しかないのに、なんでエラーになるのかわからないところがあって、最終的にライブラリの中身を編集して完成させるという暴挙に出た)

推論重要

「こうなってる?→なってたらここはこうなって、こっちはこうなってるはず→なってた!!!」というプロセスを繰り返せていて、特に何もドキュメントを読むことなくSpring Frameworkの外観を把握できた。なので今ドキュメントを読むと相当いろんなことがわかるようになっていると思っている。

新しいことを学ぶときは他人が書いたコードが一番勉強になる

ドキュメントを読むより、人が時間かけて書いてくれたコードをガンガン読んだ方がドキュメントより正確だし、自分で思考して推論していけるのでよかったと思う。

たぶんドキュメントを読んで自分でSpring Frameworkの環境を構築してJavaで書いていくより、効率的に学習できた。

ただし、既知の概念だけでは得るのが難しいような概念(自分にとって完全に馴染みのない概念)は、おそらくそもそも推論の原理的に難しくて、未知の情報に対して既知の情報が足りなさすぎて、解決への探索に計算リソースが膨大に必要になると思った。

だから、情報量が格段に多い、いわゆる難しい概念を日常的に獲得していくことで、他分野の知識も得られやすいのかなと感じた。

英語できないとつらすぎ

ハッカソンの最初で、アメリカ人の人が最近の動向とかを説明してくれていた。1時間ぐらい。最初は日本人向けに英語をゆっくり話していたけど、慣れてきたのかだんだん早くなっていき、そもそもよくわかっていないものをよくわからない単語と組み合わされて話されていたので、一部理解できても、ものすごくつらかった。

ふつうに英語の重要性を感じた。

おもったこと

最近本業でわけわかんないのにインフラ周りばかりやっていてスランプぎみだったので、集中してコーディングできて、一つのものを作り上げることができたのは、精神衛生的に良かった。

なので、こういう本業とは直接関係ない、やつあたりみたいなコーディングも時々やるのがいいかなと思った。

Spring Frameworkがどうこう以上に(たぶん個人的には使わないし)、色々と教訓が得られたのがよかった。

振り返ってみると全然大したことしてないので、たとえばDIのへんとか勉強したいと思った。

🐹

「この問題は本当に問題です」に触発されて問題作った

人に「この問題は本当に問題です」の問題が「これおもしろい。こういうの解きたい」って言われたので「じゃあ作ってあげる」ということでつくった。

いちごを5つ入れられる袋が8つあります。
その袋のうち半分にいちごを入れられるだけ入れ、
残りの袋には3つずつ入れます。
こうして作った袋をすべて入れたダンボールを1箱として、
AさんはBさんに1箱300円で6箱売りました。
Bさんが渡された箱をすべてあけてみると、
中のいちごの半分が腐っていました。
いちごの価値を1つ10円とすると、
Bさんはいくら損をしたでしょう?

けっこうめんどくさいはず

交通費のスクレイピングとかだるいのでAlfredのWorkflowとシェルスクリプトで調べるようにしてみた

はじめに

仕事中に気まぐれに読んでた記事があったので、すぐできそうだしあったら便利だなと思って、アイディアを丸パクリして実装してみました(今も仕事中)

ascii.jp

前提条件

  • Alfredがインストールされていること
  • Alfredが課金版であること

使い方

Ctrl + Space で Alfredというアプリを呼び出したあと、 eki 東京 名古屋 のようにスペースを開けて検索すると値段を表示してくれます。

f:id:haruharu1:20180807120409p:plain

f:id:haruharu1:20180807120403p:plain

作ったやつの置き場所

2018-08-07_atb6d37d | Files.fm.

これをAlfredワークフローに追加すればいけると思います(てきとう)

ここからダウンロードするの怖い人は自分で作ってください

おまけ

ワークフロー

f:id:haruharu1:20180807120759p:plain

スクリプトの中身はこんなかんじです。

query=$1

q1=$(echo "$query" | cut -d ' ' -f1)
q2=$(echo "$query" | cut -d ' ' -f2)

open "https://www.jorudan.co.jp/norikae/cgi/nori.cgi?Sok=%E6%B1%BA+%E5%AE%9A&eki1=$q1&eok1=R-&eki2=$q2&eok2=R-&eki3=&eok3=&eki4=&eok4=&eki5=&eok5=&eki6=&eok6=&rf=nr&pg=0&Dym=201808&Ddd=7&Dhh=11&Dmn=37&Cway=0&C1=0&C2=0&C3=0&C4=0&C6=2&Cmap1=&Cfp=1&Czu=2"

リファレンス

Splitting a query into two variables - Discussion & Help - Alfred App Community Forum

Jmeterを使ったDDoS的な負荷試験のやりかた

jmeter-serverを使って、jmeterクライアントから「これで動かして〜〜」という旨を、いろんなクライアントに送り、最終的にDDoS的な攻撃ができる。

注意

jmeter4.0だとリモートで動かなったりする。RMIのNotSerializableExceptionとかが出る(´・ω・`) なぜかは不明。

3.3をインストールするとあっけなく使えるので3.3推奨。

jmeterそのものの使い方は知っている前提で書くので、普通のjmeterの使い方の範疇に入るような、自明なことは特に説明しない。

また、通読にはインフラエンジニアの初歩的な知識を要求する。

概要

コンピュータをたくさん使う。

構成は、Master/Slave構成というか、1クライアント+複数サーバという構成

Jmeterクライアントから、複数のJmeterサーバに「こういう感じで試験やってよ」という指令を送り、Jmeterサーバは、ターゲット犠牲者に対してリクエストを送る

Jmeterサーバ、Jmeterクライアントでそれぞれ設定が必要。けっこうセンシティブなので、雑なコンフィグだとすぐにエラーをはいてくれる。

サーバとクライアントが一体化しているので、jmeterをインストールしたらサーバ機能もクライアント機能も入っている。

クライアントとサーバの通信はRMIとかいうJavaのリモートプロシージャコール(RPC)的なのを使う。そのためのポートは自由に指定できる。ちなみにぼくはRPCをよくわかってない。誰か教えてください。

この人の説明がわかりやすい(英語) ↓

https://www.artofsoftwaredevelopment.com/performance/performance-testing-in-the-cloud-with-jmeter-aws

↑の記事と、この記事で疑問点はほぼ解消されると思う(たぶん)

やることの順番

・インスタンスを複数用意(クライアント用1つとサーバ用複数)
・それぞれに同じバージョンのjmeterをインストール。Javaも同じ必要がある(らしい。別に違ってもいけるときとかあるし)
・jmeterサーバの設定をする(全サーバ同じでいい)
・jmeterクライアントの設定をする
・jmeterサーバの起動
・jmeterクライアントから負荷試験の指令を送る

いきなり100台たてて全部設定とかしてるとサーバ費用で死ねるので、まずはローカルで試して、おkそうならサーバを2台立てて試し、その後3台にして、そのあとで100台でやるとかの方がいいと思われる。

jmeterのインストール

ここから3.3をもってくる。4.0はカッコいいけど動かない。普通に動かす分にはよさげ。インストールは、zipとかtgzを展開するだけ。

https://archive.apache.org/dist/jmeter/binaries/

インスタンスjavajmeterをインストール

java8とかjava9がいいらしいぞ

↓ Ubuntu16.4だとこんなん

How to Install Oracle Java 8 / 9 in Ubuntu 16.04, Linux Mint 18

設定

ここにする。サーバ側の設定もクライアント側の設定もここでするので、間違えないようにする。

$ vim apache-jmeter-3.3/bin/jmeter.properties

サーバ側の設定

ポート番号に大した理由はない。自由に設定していいけど、この番号で設定していることを前提に話を進めるので変えたい人はそこに注意。デフォルトは1099だけど使いたくない。

server_port=24001
server.rmi.localport=26001

クライアント側で結果を受け取るための設定をする

設定しないとデータを受け取るためのポート番号がランダムに変わる(なんだその仕様・・・)

こちらもポート番号に大した理由はない。自由に設定し(ry

client.rmi.localport=25000

ポートについて

AWSでやる場合は、これらのポートをもとにしたセキュリティグループをつけたりして、上記のポート番号を許可しないと途中でとまる(あたりまえ)

本当はセキュリティグループは22番だけにして、SSHトンネリングをしたほうがセキュアなのでいい(めんどくさいけど)

SSHトンネリングはするとhostnameで判定するため、127.0.0.1とか10.0.255.238とかlocalhostとかいろいろややこしくてめんどくさくなる。特に複数あるとSSHトンネリングだけでしんどい。

ぶっちゃけ一瞬ポート開けたぐらい大丈夫だし、しかも仮に乗っ取られてもすぐインスタンス停止するから大丈夫だろとか思ったりとかもしない。

でもセキュアにしたい場合はSSHトンネリングしたり、めんどかったらAWSのセキュリティグループでプライベートIP指定したりする。後者の方が楽。

jmeterサーバの起動

これを複数のサーバで実行する。別に ./jmeter -s でもいいけど、どっちでもいい。

$ ./jmeter-server

SSHトンネリングとかするために、ホスト名を入れる場合はこんなかんじで。

$ ./jmeter-server -Djava.rmi.server.hostname=localhost

jmeterクライアントから負荷試験の指令を送る

こんなかんじ。jmxファイルは、jmeterで保存したテストプランのファイル。詳細はぐぐれ。

-R を使うと、通信先を指定できる。カンマで区切って複数指定する。

$ ./jmeter -n -t 【GUIのJmeterで保存したテストプランのファイル(拡張子は.jmx)】 -l 【出力ファイル(csv形式で出力される)】 -R 10.0.255.238:24001,10.0.255.237:24001

オプションの意味に関しては $ ./jmeter -\? で見れるので、そちらを参考に。

コマンドラインで複数指定したくない場合は、クライアントの jmeter.properties

remote_hosts=10.0.255.238:24001,10.0.255.237:24001

のように書いて、

./jmeter -n -t 【GUIのJmeterで保存したテストプランのファイル(拡張子は.jmx)】 -r -l 【出力ファイル(csv形式で出力される)】

でよい。

SSHトンネリングなどしてホスト名がある場合はやはり -Djava.rmi.server.hostname=localhost をつける。

これで終わり。

リファレンス

keystoreの設定方法

Apache JMeter - User's Manual: Remote (Distributed) Testing

keystoreのパスワードがおかしいとか言われた

java - keytool error Keystore was tampered with, or password was incorrect - Stack Overflow

SSHトンネルする

How to run jmeter over ssh tunnel | ionel's codelog

やり方について

Performance Testing in the Cloud with JMeter & AWS

marshalexceptionについて

(ロシア語) azure - Jmeter MarshalException: аргументы сортировки ошибок - Qaru

azure - Jmeter MarshalException: error marshalling arguments - Stack Overflow

サーバがビジーって言われたら

Killすればおk

distributed - JMeter: JMeter remote test fails with error as "Engine is busy, Please try later" - Stack Overflow

SSHトンネリングに使いそうなスクリプト

# sh tunneling.sh [localport] [target-ip]
second_localport=$(($1 + 2000))
echo "$1 port is used and target ip is $2"
ssh -L $1:localhost:24001 -R 25000:localhost:25000 -L $second_localport:localhost:26001 -N ubuntu@$2 -i ~/.ssh/jmeter-stress-test.pem -f

まとめ

これでインスタンスの数だけリクエストを送りまくれる。

50万リクエスト/秒とか飛ばして人のサーバをぶっつぶせるので楽しい!タノシイ!タノシイ!

誰かのクレカさえ奪えれば気軽にDDoSできる世の中すごい怖い。

ちなみに攻撃ツールとしては指令が失敗した場合止まるのであんまり役に立たないと思います。

たのしい負荷試験ライフを!

免責

免責があります。

HTMLでエスケープするときに使う&quot;とか&#34;とかについて

「HTML特殊文字」とか「HTMLエスケープシーケンス」とか「HTMLのエスケープ文字」とか言うと混乱する場合があるのでちゃんとした名前を使う。

たとえばパーサ書いてレンダリングしてるときに、こっちのエスケープにあっちのエスケープしてこっちのエスケープがとかやってると、何のエスケープかわからなくなりバグ修正のときに困る。

それで、なんか長年ずっとたたずんでいるこうした「HTML特殊文字」に、パッと調べた感じビシッとした感じの日本語訳ないので人と情報が共有できない。

なのでまとめてみた。

公式名称はw3.orgから引用したよ。

Using character escapes in markup and CSS

数字のやつ【&#34;や&#x34;】

10進数は

decimal numeric character reference

16進数の方は

hexadecimal numeric character reference

俗称:

Numeric Character Entity
Numeric Code Character Entity
Numeric Code Character
Numeric Character Reference
NCR

Numeric character reference - Wikipedia

名前のやつ【&quot;とか&amp;とか】

named character reference

俗称:

Character Entity
Character Entity Reference
NCR
HTML entity 

参考:

Character entity references in HTML 4

ぼくの使い分け方

対象 よびかた
とくに使い分けないとき NCR
10進数の 10進数のNCR
16進数の 16進数のNCR
数字の Numeric Character Reference / 数字の方のNCR
名前のやつ Named Character Reference / 名前の方のNCR
NCRの表のこと NCRs

 

ひろめていきたい(`・ω・´)ゞ

おまけ

HTMLではエスケープはNCRを使いましょう(1敗)

<div id="1" attribute="a\"b">だめ</div>
<div id="2" attribute="a&quot;b">おk</div>

<script>
var divs = document.querySelectorAll('div')
divs.forEach(e => {
  console.log('ID', e.getAttribute('id'))
  console.log('attribute', e.getAttribute('attribute'))
})
</script>
ID 1
attribute a\
ID 2
attribute a"b

その他

もうちょっと詳細書いたのがあるので、興味がある方はこちらへどうぞ

ㇹ゚ン゚'ㇳ̃ヴ゙ニ゙コ゚ヮヰ文̂字̠コ゚−ト゚ノ゙ㇵナ゚ㇱ(現在に至るまでの文字コードの軌跡と簡単な使い方について) - へっぽこびんぼう野郎のnewbie日記