2020/09,江端さんの忘備録

国家間の戦争が、経済を大きく回す ―― そんなことは、今時、子どもだって知っています。

"War between nations turns the economy around in a big way" -- even children know that nowadays.

私なんて、アニメで再履修したくらいです。

I even took a refresher course in the anime.

「まおゆう魔王勇者」っていうんですけど、最近のアニメは原作者の方が本当によく勉強されていて、大変助かります。

It's called "Mao Yu Maou Brave". In recent anime, the original author studies really well, so their works help me.

このアニメが教えてくれることは、戦争経済は、開始とその最中は調子が良くても、それを無策に停止させる(和平に導く)と、国家を壊滅させかねない恐しい不況が発生するということです。

What this anime tells us, is the fact is that the war economy is in good shape at the beginning and during it, but if it is stopped without any measures (leading to peace), there will be a terrible recession that can destroy the nation.

例えば、日本史の中にあっても、その事例は簡単に見つけられます。

For example, even in Japanese history, you can easily find the case.

例えば ―― 天下平定後の豊臣秀吉が、不可思議とも思える侵略戦争「文禄・慶長の役」を試みたのは、戦場がなくなった日本国における、戦闘員(武士)による、大量失業対策であった ―― ということは周知の事実です。

For example-- that is a well-known fact. The reason why Toyotomi Hideyoshi attempted the mysterious war of invasion, "The War of 1592", after the pacification of the country, was as a countermeasure against mass unemployment for the combatants (samurai) in Japan, which had lost its battlefield.

-----

あまりにも自明であるけど、不謹慎だから口にしない。

It's too obvious, but I'm not going to talk about it because it's immodest.

その筆頭が、「国家間の戦争が経済を大きく回す」というフレーズです。

The first of these is the phrase "War between nations turns the economy around in a big way".

-----

アニメで教えてくれる程度のことを、またどこぞの誰かが口にして、問題になっているようです。

It seems that there is a problem when somebody talks about the things that are taught in the anime.

しかも、今回は「コロナ禍」という言葉を使ったことで、世間の"不快"を買ってしまったようです。

Moreover, he seems to have caused public "discomfort" by using the term "corona disaster" this time.

『いい大人が、そんな「中二病」発言なんかして、みっともないことだな』 ―― と、ニュースを見ていたら、どこぞの市の教育長でした。

It's disgraceful for a grown man to make such a 'junior high' comment. I was watching the news and I knew he was the superintendent of education in some city.

「なるほど」と、なんとなく納得してしまいました。

"I see". I was somewhat convinced.

-----

私、この教育長なる人を擁護する気は1mmもないのですが、

I'm not trying to defend this school superintendent at all, however,

個人的には、

personally.

2015年の夏、鹿児島県の県知事が『女子高生は、三角関数より花や草の名前を教えた方がいい』と発言して大問題に発展しました

In the summer of 2015, the governor of Kagoshima Prefecture got into big trouble when he said, 'High school girls should be taught the names of flowers and grasses rather than trigonometric functions'.

の方が、怒りとしては大きいです。

I am furious with this phrase.

で、今後、同じような事件(舌禍事件)が発生する度に、このページを引用して、世間から忘れされることがないよう、努めるつもりです。

And every time a similar incident (tongue-in-cheek incident) occurs in the future, I will try to cite this page so that it will not be forgotten by the public.

-----

どうせ"舌禍"かますなら、言い訳の余地もないほど、徹底的に、激烈にやるべきです。

If you're going to create a "tongue-in-cheek" problem, you should do it so thoroughly and violently that there's no excuse for it.

例えば、

For example,

頭のイカれた教祖と、それを信奉する無知性な信者からなるカルトな宗教団体

A cult-like religious group made up of a crazy guru and the ignorant followers who follow him.

くらいの、悪意と憎悪を込めたフレーズをかますべきです。

You should use phrases with this level of malice and hatred.

2020/09,2020/09,江端さんの忘備録

私は、自分の娘たちに、若いころの恋愛話を―― 客観的に、他人事のように ―― ペラペラとしゃべっています。

I talk to my daughters about my youthful romance objectively, like other's love affairs.

それを受けてか、我が家の娘たちも、現在進行形の話を、私に話します(当然、開示内容には制限はかかっているでしょうが)

After that, my daughters also tell me the ongoing story (although the disclosure may be limited, of course).

-----

最近、娘にウケたネタとしては、

Recently, as a fummy story that my daughter got

―― 運命の赤い糸は、自分を中心として1024本ほど同時に繋っていて、そのいずれも確定状態にはない

"The 1024 red threads of destiny are connected at the same time, centering on you, and none of them are in a confirmed state"

という、最近の私の『量子論』の勉強に基づく、いわゆる「量子恋愛論」でした。

That was the so-called "quantum love theory" based on my recent study of "quantum theory".

-----

その話を聞いた娘は、大爆笑していました。

After hearing the story, she was laughing loudly.

彼女に何があったのかは知りませんが、『まあ、がんばれ』とだけ、言っておきました。

Though I don't know what happened to her, I told my daughter, "Well, do your best."

2020/08,江端さんの忘備録

本日は、コラムがリリースされた日なので、日記はお休みです。

Today, new my column is released, so I take a day off.

踊るバズワード ~Behind the Buzzword(5)量子コンピュータ(5):

量子もつれ ~アインシュタインも「不気味」と言い放った怪現象

Dancing Buzzword-Behind the Buzzword (5) Quantum Computer (5)

Quantum entanglement - the phenomenon that even Einstein called "uncanny"

-----

『量子の振舞いの不気味さに比べたら、幽霊とかお化けなどの怪談の怖さなんぞ、お話になりません(本当)』

Compared to the creepiness of quantum behavior, there's nothing in the horror of ghosts and the stories (really).

については、今回全部書いてしまったので ―― もう、このネタついては、もうこれ以上記載することがありません。

ただ気になっているのは、今回の「量子もつれ」の調査で、私のように、「分からん!」「不可解!」とか叫んでいる文献とか論文とかを、まったく見つけられなかったことです。

There are just things I'm curious about. In this "Quantum Tangle" survey, I couldn't find any literature or papers that shouted "I don't know!" "Mysterious!" like my column.

さらっと、『このような現象を"量子もつれ"という』というフレーズがあっただけで、そこには、この現象に対する本質的なリアクション

After all, there was only the phrase "a phenomenon like this is called "entanglement"", and there is no essential reaction to this phenomenon. It is an

―― 驚愕

"Astonishment"

が、ないのです。

学術論文の記載であっても、

Even the description of an academic paper,

『現時点で、この「量子もつれ」という「量子の非局所性」は、観測をベースとする古典力学の観点からは『非常識』としか思えないような物理現象である』

"At present, this "non-locality of quantum" called "quantum entanglement" is a physical phenomenon that can only be considered as "insane" from the viewpoint of classical mechanics based on observations."

の一文があっても良いと思うのです。

I wanted to read the above phrase.

論文や著書の執筆者は、自分が驚いたり、狼狽(うろた)えたりしていることを、「かっこ悪い」とでも思っているかのようです。

It's as if the authors of papers and books think it's "uncool" to be surprised or dismayed.

-----

私は、

I believe that

■科学という学問の本質は、「感情(驚愕や畏怖)」にあり、

"The essence of the science is "feelings (startle or awe)""

■工学という学問の本質は、「失敗と繰返し」にある

"The essence of engineering is "failure and repetition"

と信じています。

故に、私は自分の素直な感情をコラムで吐露(とろ)し、失敗した事例(プログラム等)をブログにアップロードして、世界に晒しています。

Therefore, I show my honest feelings in the column, upload the failed cases (programs, etc.) to the blog, and expose them to the world.

それらは、科学や工学の進歩に絶対的に必要なことだ、と確信しているからです。

I am convinced that they are absolutely necessary for the advancement of science and engineering.

-----

"ちんけ"な成功例(実験条件を限定した、都合の良い設定でのコンピュータシミュレーションなど)で、論文を量産する研究員やエンジニアなんぞより、

In a "cheap" success example (computer simulation in a convenient setting with limited experimental conditions, etc.), the researchers and engineers who mass-produce papers,

誤解に基づくコラムや、膨大な失敗例を、臆面もなく量産し公開し続けている私の方が、よっぽど「役に立っている」と思っています。

I think I'm much more "helpful" than them even if I keep mass-producin and publishing columns based on misconceptions and a lot of failures.

-----

もちろん、偉大な発見や発明をした人/する人の「役の立ち方」には、遠く及びませんが ――

Of course, it's not far from the "helpfulness" of the person who made/will make the great discoveries and inventions.

それでも、"ちんけ"な研究員&エンジニアには、"ちんけ"なりの人類への貢献方法があるんですよ。

However, "cheap" researchers and engineers have "cheap" ways to contribute to humanity.

"ちんけ"な奴が、もっとも偉大な発見や発明をする人の振舞いを「まね」したところで、何の役にも立ちはしません。

The "cheap" guy does nothing to imitate the behavior of the greatest discoverer or inventor.

-----

"ちんけ"な研究員&エンジニアは、『一生、見苦しく生きて行く』でいいんです ――

"Cheap" researchers and engineers are good at "living unsightly for the rest of their lives".

世界中の誰もが認めなくても、この私だけは、その生き方、認めます。

Even if no one in the world understand it, I can accept you.

2020/08,江端さんの忘備録

(昨日の続きです)

(Continuation from yesterday)

私たちは、高校数学で「虚数」やら「虚数空間(複素平面)」という考え方を学びます。

We learn the concept of "imaginary numbers" and "imaginary spaces (complex planes)" in high school mathematics.

「虚数」という名称を付けられてはいますが、虚数空間は、現実空間からは死角に入っている(直交している)だけで、ガッツリと存在している空間(直交空間)です。

Despite the name "imaginary", imaginary space is a space that exists in reality (orthogonal space), but is only in a dead angle (orthogonal) from real space.

リアル充実、いわゆる「リア充」という既存の価値観に対して、

As opposed to "Really fulfillment", so-called "RE-life"

「レンタル彼女/彼氏」は、直交空間における新しい価値観、

the "rent-a-girlfriend/boyfriend" is a new value in the orthogonal space,

―― イマージナリ充実、略して「イマ充」

"Imaginary fulfilling", or so-called "IM-life"

として認識されるべきでしょう。

We should recognize it.

もう一歩前進して考えてみれば、「愛」というものそのものが、「リア充」軸と「イマ充」軸からなる平面上での周期運動するベクトルのようなものです。

If you take it one step further, "love" itself is like a vector in cyclic motion on a plane consisting of a "RE-life" axis and an "IM-life" axis.

-----

「リア充」軸上で停滞しているベクトルの一例では、「バカップル」があります。

In an example of a vector that is stagnant on the "RE-life" axis, there are "love birds".

停滞しているベクトルには運動エネルギーがないので、当然のことながら、「バカップル」は、そのライフタイムは恐しく短いです。

Unsurprisingly, "love birds" have a frighteningly short life-time, since stagnant vectors have no kinetic energy.

逆に、「イマ充」軸上で停滞しているベクトルの一例が「レンタル彼女/彼氏」になるのでしょう。

On the other hand, in an example of a vector that is stagnant on the "IM-life" axis, it would be a "rent-a-girlfriend/boyfriend.

このベクトルも運動していませんので、エネルギー(現金)の供給が無くなった時点で消滅する、という点では同じです。

This vector is also not in motion, so it is the same in that it disappears when the supply of energy (cash) is no longer available.

逆に言えば、エネルギー(現金)の供給が続く限りは、存続できるのです。

Conversely, as long as the supply of energy (cash) continues, it can survive.

-----

『「愛」を維持する為のエネルギーが「愛自身」しかない』というのは狭量で短絡的な上、ズルい考え方です。

It is a narrow, short-sighted and unfair way of thinking to say that "the only energy available to maintain love is love itself".

私達は、「愛」の代替エネルギーとして、パートナーの

We use our partner's attributes as an alternative energy for "love", for example,

「理念」「教養」「趣味」「嗜好」、そして「愛想」「外観」「年齢」、更には「学歴」「地位」「収入」等

ideas, culture, hobbies, tastes, and preferences, appearance, age, and even education, status, income, etc.

を活用しています。

この事実を「公に」否定できる人は、一人もいないはずです。

Not a single person should be able to "publicly" deny this fact.

2020/08,江端さんの技術メモ

  • 概要
    • Webシステムを外部から利用するためのプログラムの呼び出し規約(API)
    • リソースの操作はHTTPメソッドによって指定(取得ならGETメソッド、書き込みならPOSTメソッド)される
    • 結果はXMLやHTML、JSONなどで返される
    • 処理結果はHTTPステータスコードで通知する
  • RESTの基本仕様
    • セッション管理を行わない
    • 情報を操作する命令の体系が予め定義(HTTPのGETやPOSTメソッドなどで)されている
    • 汎用的な構文で識別される(URLやURIなど)
    • 情報の内部に、別の情報を含めることができる
    • リソースに対してURLが対応づけられる
    • 「GET」なら取得、「POST」なら作成、「PUT」なら更新、「DELETE」なら削除のように処理する
  • ここから先は、Golangの開発プロセスになる
    • go get -u github.com/gorilla/mux を行う

golangでシンプルなRESTful APIを作ってみよう!を、そのまま書き下してトレースで動きを追ってみました。

今回から、emacs + gdb を断念して、Visual Studio Code を使ってみました。うん、死ぬほど便利。

//C:\Users\ebata\go_rest\restful\main.go
 
package main

import (
	"encoding/json"
	"fmt"
	"log"
	"net/http"
	"strconv"

	"github.com/gorilla/mux"
)

// Item representation
type Item struct {
	Title       string `json:"title"`
	Description string `json:"description"`
}

// Global, static list of items
var itemList = []Item{
	Item{Title: "Item A", Description: "The first item"},
	Item{Title: "Item B", Description: "The second item"},
	Item{Title: "Item C", Description: "The third item"},
}

// Controller for the / route (home)
func homePage(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintf(w, "This is the home page. Welcome!")
}

// Contoller for the /items route
func returnAllItems(w http.ResponseWriter, r *http.Request) {
	respondWithJson(w, http.StatusOK, itemList)
}

// Controller for the /items/{id} route
func returnSingleItem(w http.ResponseWriter, r *http.Request) {
	// Get query parameters using Mux
	vars := mux.Vars(r)

	// Convert {id} parameter from string to int
	key, err := strconv.Atoi(vars["id"])

	// If {id} parameter is not valid in
	if err != nil {
		respondWithError(w, http.StatusBadRequest, "Invalid reqest payload")
		return
	}

	// If item with ID of {id} does not exist
	if key >= len(itemList) {
		respondWithError(w, http.StatusNotFound, "Item does not exist")
		return
	}

	respondWithJson(w, http.StatusOK, itemList[key])
}

func respondWithError(w http.ResponseWriter, code int, msg string) {
	respondWithJson(w, code, map[string]string{"error": msg})
}

func respondWithJson(w http.ResponseWriter, code int, payload interface{}) {
	response, _ := json.Marshal(payload)
	w.Header().Set("Content-type", "application/json")
	w.WriteHeader(code)
	w.Write(response)
}

func handleRequests() {
	myRouter := mux.NewRouter().StrictSlash(true)
	myRouter.HandleFunc("/", homePage)
	myRouter.HandleFunc("/items", returnAllItems)
	myRouter.HandleFunc("/items/{id}", returnSingleItem)
	log.Fatal(http.ListenAndServe(":8000", myRouter))
}

func main() {
	handleRequests()
}

http://localhost:8000/ → ホームページ、テキスト("This is the home page. Welcome!")を見せる

http://localhost:8000/items → "[{"title":"Item A","description":"The first item"},{"title":"Item B","description":"The second item"},{"title":"Item C","description":"The third item"}]"

http://localhost:8000/items/1 → {"title":"Item B","description":"The second item"}

なるほど、こんな感じで使うのね。

ーーーーー

jsonの使い方についても、Go言語でJSONを扱う を写経させて頂いた。

vro.json

[
    {"id":1, "name":"akane","birthday":"08-16","vivid_info":{"color":"red","weapon":"Rang"}},
    {"id":2, "name":"aoi","birthday":"06-17","vivid_info":{"color":"blue","weapon":"Impact"}},
    {"id":3, "name":"wakaba","birthday":"05-22","vivid_info":{"color":"green","weapon":"Blade"}},
    {"id":4, "name":"himawari","birthday":"07-23","vivid_info":{"color":"yellow","weapon":"Collider"}}, 
    {"id":0, "name":"rei"}    
]

vro.go

package main

import (
	"encoding/json"
	"fmt"
	"io/ioutil"
	"log"
)

/** JSONデコード用の構造体定義 */

type Person struct {
	Id       int      `json:"id"`
	Name     string   `json:"name"`
	Birthday string   `json:"birthday"`
	Vivid    struct { // 構造体の中にネストさせて構造体を定義
		Color  string `json:color`
		Weapon string `json:weapon`
	} `json:"vivid_info"`
}

func main() {
	// JSONファイル読み込み
	bytes, err := ioutil.ReadFile("vro.json")
	if err != nil {
		log.Fatal(err)
	}
	// JSONデコード
	var persons []Person
	if err := json.Unmarshal(bytes, &persons); err != nil {
		log.Fatal(err)
	}
	// デコードしたデータを表示
	for _, p := range persons {
		fmt.Printf("%d : %s : (%s) [%s]\n", p.Id, p.Name, p.Vivid.Color, p.Birthday)
	}

	// JSONデコード
	var decode_data interface{}
	if err := json.Unmarshal(bytes, &decode_data); err != nil {
		log.Fatal(err)
	}
	// 表示
	for _, data := range decode_data.([]interface{}) {
		var d = data.(map[string]interface{})
		fmt.Printf("%d : %s\n", int(d["id"].(float64)), d["name"])
	}
}

2020/08,江端さんの忘備録

『フィクションにしても、ちょっと(私には)合わないなぁ』と思って、視聴してはいませんが、「恋人をレンタルする」というテーマのアニメがあるようです。

I thought "Even if it's fictional, it's not quite (for me)" about an anime about "renting a lover". so I haven't watched it.

しかし、そのコストや業務形態には興味がありました。

However, I was interested in the costs and business model.

でもって、ちょっと調べてみたら、出るわ出るわ、山程の「レンタル彼女」「レンタル彼氏」の紹介サイト。

But when I did some research, I found a lot of sites that introduce "rental girlfriends" and "rental boyfriends".

正直、ちょっと引いてしまう程でした。

That kind of site was a real turnoff.

-----

しかし、考えてみれば、「レンタル彼女/彼氏」は、普通にビジネスとして成立するはずで、別段、驚くことでもないはずです。

But thinking it again, "rental girlfriend/boyfriend" should be a normal business, and it shouldn't be a surprise to me.

接待を伴う飲食業の「店舗外バージョン」です。

This is the "out-of-store" version of the restaurant business with entertainment.

「デートできればそれで足る」というニーズに対して、Win-Winのリソース活用(金と時間の交換)とも言えます。

It can be seen as a win-win resource utilization (exchange of money and time) for the needs of "If I can date, it's good enough".

これは「デートのクラウド化」であり、ITの世界では当たり前の「リソースシェアリング」です。

This is the "cloud of dating" and "resource sharing" that is commonplace in the IT world.

その他のメリットを上げれば、(1)デートのフィールドトライアル、(2)本番デートの前のチェックリストやデバッグ、(3)孤食の回避、(4)服飾系のコンサルタント、等々。

Other benefits include (1) field trials for dates, (2) checklists and debugging before the real date, (3) avoidance of isolation, (4) clothing consultants, etc.

それ以外では、(A)結婚圧力の強い環境(肉親、地域、組織(会社))、(B)同性愛等の無理解な環境、あるいは(C)「一人ぼっちは体裁が悪い」と考えている人にとっては、一種の「擬態」としても有効なのかもしれません

Otherwise, it may be useful as a kind of "mimicry" for people who (a) are in an environment of strong marriage pressure (immediate family, community, organization (company)), (b) are in an environment where there is no understanding of homosexuality, etc., or (c) think that "being alone is bad for their appearance"

―― 知らんけど。

I don't know them well.

(続く)

(To be continued)

2020/08,江端さんの技術メモ

  1. まずは、MSYS2をメンテナンス(2年近く放置していたから)
$ pacman -Syu

を、ターミナルを何度も立ち直し続けてパッケージの更新を繰返す。

$ pacman -S base-devel
$ pacman -S msys2-devel
$ pacman -S mingw-w64-x86_64-toolchain
$ pacman -S mingw-w64-x86_64-gnutls
$ pacman -S mingw-w64-x86_64-ruby
$ pacman -S nano      #(簡易エディター)
$ pacman -S make      #(make をインストール ※重要※)
$ pacman -S openssh   #(openssh をインストール)
$ pacman -S git       #(Git をインストール)
$ pacman -S ruby      #(Ruby をインストール)
$ pacman -S ruby-docs #(Rubyドキュメント をインストール)
$ pacman -S p7zip     #(7z をインストール)
$ pacman -S mingw-w64-x86_64-ag  #(ag 高速検索コマンドをインストール)

2. パッケージのインストールとアンインストール

sudo pacman -S [パッケージ名]
sudo pacman -R [パッケージ名]

3. Windows10の環境をMSYS2に引きつぐ方法

2020/08,江端さんの技術メモ



go func() { defer close(done) for { _, message, err := c.ReadMessage() if err != nil { log.Println("read:", err) return } log.Printf("recv: %s", message) } }() ticker := time.NewTicker(time.Second) defer ticker.Stop() for { select { case <-done: return case t := <-ticker.C: err := c.WriteMessage(websocket.TextMessage, []byte(t.String())) if err != nil {

go func()で、defer close(done)が効いてくるまで、 case <-done:はロックされて、デッドロックになるじゃないか? と、ずっと考えて訳が分からなくなってきたところで、Go言語でチャネルとselect というページに、

チャネルに値が入っていない場合、受信はブロックする。ブロックせずに処理を行いたい場合は select を使う。

そんなSwitchの使いかた、あるかーーーー! と、叫びそうになりました(私の2時間を返せ)