Hatena::ブログ(Diary)

お前の血は何色だ!! 4 このページをアンテナに追加 RSSフィード Twitter

2017-05-19

ヘイトには課税せよ(ヘイトには課金せよ)

ヘイト表現の自由の両立について。

サッカースタジアムで旭日旗が問題になっているらしい。

そもそも、なぜスポーツ会場で軍旗にも使われている(いた)旗を掲げないといけないのか?というツッコミは置いといて、

大会の規定で軍旗などの政治的な主張とされるものは禁止されるのだから、

掲げるのを禁止されるのは仕方がないところである。

だが、同時に、表現の自由も大切である。

例えクソのような主張であっても、表現の自由で守られるべきだ。

(例えば、この文章のようなクソな主張であってもね。)

表現の自由はとても大切である。

でも、その表現で、苦しむ人もいるだろう。

両方を救ううまい方法はないだろうか。


そこで、提案したいのが、

ヘイト(や場に好ましくない政治的主張やCM)は禁止ではなく、別料金をいただいて、

課金していただいた上でどうどうと掲げていただくというものだ。

例えば、規定上好ましくないものについて、お1人樣1回 300万円+消費税請求する。

テレビや新聞とかのメディアに注目される大会なんだろうから、

そこで特別な主張をしたいと言うならば、

選挙供託金の額と同じ300万円ぐらいは最低でも払っていただきたいところである。

横断幕やノボリなどのようなでかいものについては、別途割増をいただく。

それはヘイト(や規定で禁止されている政治的な主張等 以下:ヘイト)であると注意しても、

やめない場合は、上記料金を請求する。

そして、

頂いた300万円の半分を、その主張で被害を受けるであろう人たちの団体等に寄付する。

もう半分は、スタジアム運営者や、スポーツチーム等で分配する。


禁止ではなく、ここでそれをするには課金してくださいというのは、表現の自由に反しない。

例えば、サイトにバナー広告を乗せるのにはお金が必要である。

テレビCMを流すのにはお金が必要である。

これらと同じくまったく問題がないわけだ。

酒やたばこなどの好ましくないとされるものには、税金を多めに取って認めるようなものである。


この案の面白いのは、

頂いたお金の半分を、その主張で被害を受けるであろう人たちの団体に寄付するところである。

つまり、ヘイトをすればするほど、ヘイトされる人たちが潤うという仕組みである。

もし、3人が年10回ほどヘイトしていただくと、

300万円*10回*3人=9000万円 の半分で、4500万円ほどのお金がヘイトで被害を受けるであろう団体に行く。

ヘイトされる側の人々は、我々の心の傷はそんなものではないといわれるかもしれないが、

タダでヘイトされている現状よりはマシだろう。


そして、何より、ヘイトすればするほど、ヘイトされる側が儲かるならば、馬鹿らしくなってヘイトをやめてくれるかもしれない。

もし、馬鹿らしくなって、ヘイトをやめていただければ、これほどいいことはない。

さらに、残りの半分の4500万円は、スタジアムとスポーツチームに行く。

運営費のタシにでもしていただければ良いだろう。

さらにおまけで、消費税8%が別途入る。9000万円の8%は 9000万円*8%=720万円 である。

このお金が国や自治体に納付されることになる。

福祉や教育にでも回してほしいものである。

スタジアムやスポーツチームが、利益を上げれば、所得税法人税でもお金が入るので、さらに国庫が潤うことが期待される。

つまり、ヘイトに課金をすると、

表現の自由が守られ、(お金を払えば)好きな表現を好きなだけでき、

一方それによって、ヘイトされ傷つく人々が潤い、スタジアムやスポーツチームが潤い、税金で国庫も潤う。

誰も困らない、みんなハッピーになれるのではないだろうか。

2017-04-21

AOK 代理戦争を復旧

f:id:rti7743:20170421074941j:image

昔作った AOK代理戦争を復旧させた。

http://d.hatena.ne.jp/rti7743/20140725/1406275415

ダウンロードはこちらか、steamワークショップから

http://rtilabs.rti-giken.jp/files/2017_02_13/dairi-sensou.7z

http://steamcommunity.com/sharedfiles/filedetails/?id=917216334

基本的に、自分は交戦しないで、友軍を支援して戦わせるというとても簡単なマップです。

ただし、後半は・・・

代理戦争 ver3
Proxy war

シングルモードのシナリオです。
It is a single mode scenario.


自陣と、支援先(赤)は、山で完全に分離されています。
My team and the Partner(red) are completely separated in the mountains.

森や山があり、上下を行き来することは出来ません。
There are forests and mountains, you can not go up and down.


自陣には、同盟している交易先(緑)と大量の資源が大量にあります。
There are a large number of Trader(green) and large amounts of resources allied to their own team.

支援先(赤)がいる砂漠地帯には、ほぼ木しかありません。
There are almost trees in the desert area where there is a Partner(red).

支援先に、資源を融通して助けてあげる必要があります。
We need to help resources by Partner.


自陣の豊かな資源をひたすら採掘して、支援先に融資しまくりましょう。
Let's loan our own resources richly and loan it to the Partner.

支援先は、そのカネで軍隊を強化し、ライバルの3カ国を滅ぼしてくれるでしょう。
Partner will strengthen the army with that money and destroy the rival three countries.




なお、ライバルすべてを滅ぼした後には、おまけがありますのでお楽しみに。
In addition, after you destroy all the rivals, there is a bonus so please look forward to it.

このマップは結構初見殺しです。
This map is, You will die the first time.

セーブしながら進みましょう。
Let's proceed while saving.

FAQ
Q:
支援先が敵を倒してくれません。
The Partner will not defeat the enemy.

A:
資源をたくさん送って、ゲームスピードを早いにしてしばらく放置してください。
Please send lots of resources, speed up the game speed and leave it for a while.

攻撃はAIまかせなので、なんとも言えませんが、そのうち彼は敵を攻撃してくれます。
Since the attack is AI, I can not say it at all, but he will attack the enemy in a while.

Q:
文明の選択が気に入らない。
I do not like the choice of civilization.

A:
ご自由に改変して、遊んでください。
Please freely change it, please play.

シングルプレーのシナリオで読み込むと変えられますね。
You can change it by reading in a single play scenario.


Q:
中盤にゲームがクラッシュした
The game crashed in the middle stage

A:
中盤の演出で、まれにゲームが落ちる時があります。
In the production of the middle stage, there are times when the game falls rarely.

セーブしながら進めてください。
Please proceed while saving.


関係図
Relationship diagram

自陣(You)<-同盟(allies)->支援先(Partner)
自陣(You)<-同盟(allies)->取引先(Trader)

支援先(Partner)<-敵対(enemy)->敵A,敵B,敵C(Enemy a,b,c)
取引先(Trader)<-同盟(allies)->敵A,敵B,敵C(Enemy a,b,c)


自陣と取引先は、表面上仲がいい。
My team and Trader are on good terms.
しかし、砂漠ではそれぞれ異なる勢力を応援している。
However, in the desert, they support different forces.
冷戦時代のように。
Like the Cold War era.

仲良く握手しながら、砂漠で代理戦争を行おう。
Let's make a proxy war in the desert while sharing hands with each other.

更新 UPDATE
砂漠での戦闘が発生しやすくしました。
Battle in the desert is easy to occur.

20分後に敵BCが同盟を組むようにしました。
Enemy BC made an alliance after 20 minutes.

1時間後に、金50000と引き換えに、同盟を崩壊させられるようにしました。
After 1 hour, in exchange for 50000 gold, I made it possible to collapse the alliance.

膠着状態を避けるため、
2時間後に、敵Aが生き残っていた場合、支援先に転向し、消滅するようにしました。
In order to avoid the stalemate situation, 
if enemy A survived after 2 hours, we turned to support destination and disappeared.

3時間後に、敵Bが生き残っていた場合、支援先に転向し、消滅するようにしました。
After 3 hours, if enemy B survived, we turned to support and made it to disappear.

4時間後に、敵Cが生き残っていた場合、支援先に転向し、消滅するようにしました。
After 4 hours, if enemy C survived, we turned to a support destination and disappeared.

AOK ぐるぐる陣形

f:id:rti7743:20170421075005j:image

AIの非常に難しいで 1vs7 バトルをして勝ちたい。

でも、多方面作戦なんて無理。

深い森で引きこもっても押し負けてしまう・・・・

もっと地の利があって、敵が前からしか来ないマップがあればいいのに・・・という人のために、敵が前からしか来ないしたマップを用意しました。

ダウンロードはこちらか、steamワークショップから

http://rtilabs.rti-giken.jp/files/2017_02_13/guru2.7z

http://steamcommunity.com/sharedfiles/filedetails/?id=903937994

なんじゃーこのグルグルした陣形はー!?
ぐるぐる陣形じゃー

敵が前からのみやってくるグルグル回るマップです。
It is a map that enemies come around only from the front and go round.


シナリオモードで起動してください。
Please start up in scenario mode.

(そうしないとAIがあまり強くないので面白くありません。)
(If you do not do that, AI is not very interesting, so it's not fun.)


コンセプト
Concept

1vs7で総力戦がしたい。
I want to make a total battle at 1vs7.

でも、2正面作戦は無理。
But 2 front strategy is impossible.

それなら、敵は前からやってくるマップだったらいいよね。
In that case, the enemy should be a map coming from the front.

1vs7で、戦います。
I will fight at 1vs7.

資源は豊富にあります。
Resources are abundant.

敵は前からのみやってきます。
Enemies only come from the front.

勝利条件は制圧だけです。
Victory conditions are only control.

激戦を繰り返し、敵に勝利しましょう。
Repeat fierce battle, let 's win enemies.

2017-03-31

嫌いから好きを除いた本当に嫌われてそうなプログラム言語トップ31

開発者に嫌われているプログラミング言語トップ25という記事があった。

http://news.mynavi.jp/news/2017/03/30/133/

ただ、嫌われているといっても、それを好きという人たちもいるだろう。

だから、嫌いから好きを除けば本当に嫌われているプログラム言語がわかるというものだろうということで、さっそくなので集計してみた。

嫌いと好きを合算した結果、最も嫌われているランキング順

ランク名前嫌い好き差分
嫌われ1位Visual Basic 6-253-22点
嫌われ2位CoffeeScript-234-19点
嫌われ3位Hack-160-16点
4位VBA-249-15点
4位Lua-172-15点
6位Common Lisp-140-14点
7位Matlab-218-13点
7位Dart-130-13点
9位Erland-120-12点
10位Groovy-155-10点
11位VB.NET-2213-9点
12位Perl-1810-8点
13位Assembly-1912-7点
14位Objective-C-2014-6点
14位Julia-60-6点
16位Haskell-31-2点
16位F#-20-2点
18位R-8113点
19位Scala066点
20位Ruby-9167点
20位Go077点
22位C-10188点
23位PHP-11209点
24位C++-51914点
25位Swift01515点
26位Java-72316点
27位TypeScript01717点
28位SQL-42420点
29位Python02121点
30位C#02222点
31JavaScript-12524点

逆から見れば、最も好かれていて、アンチが少ない順番でもある。

集計方法としては、嫌われている言語トップ25と、よく使われている言語トップ25(好きな言語と仮定する)のデータをもってきて、

嫌われているならマイナス点をつける。嫌われ1位は-25点、2位は-24点、3位は-23点...25位は-1点とする。

よく使われている言語トップ25では、プラス点をつける。1位は25点、2位は24点、3位は23点...25位は1点とする。

これらの差を計算して、昇順に並べたものが、上の表である。

本当に嫌われている順番といえるだろう。

逆からみれば好かれている順番ともいえる。

本当は、生存バイアスとかもあるから、そこら辺も加味したい所でもある。

なぜなら、誕生して使われまくられればそれだけアンチも増えるというものだからな。


集計過程 嫌われている言語

開発者に嫌われているプログラミング言語トップ25

http://news.mynavi.jp/news/2017/03/30/133/

https://fossbytes.com/most-loved-and-most-hated-programming-languages/

1位Visual Basic 61位なので-25点
2位VBA2位なので-24点
3位CoffeeScript3位なので-23点
4位VB.NET-22点
5位Matlab-21点
6位Objective-C-20点
7位Assembly-19点
8位Perl-18点
9位Lua-17点
10位Hack-16点
11位Groovy-15点
12位Common Lisp-14点
13位Dart-13点
14位Erland-12点
15位PHP-11点
16位C-10点
17位Ruby-9点
18位R-8点
19位Java-7点
20位Julia-6点
21位C++-5点
22位SQL-4点
23位Haskell-3点
24位F#-2点
25位JavaScript-1点

集計過程 人気のプログラム言語2017

2017年、最も人気のプログラミング言語フレームワークデータベースは?

http://news.mynavi.jp/news/2017/03/25/208/

https://stackoverflow.com/insights/survey/2017

1位JavaScript 1位なので25点
2位SQL2位なので24点
3位Java3位なので23点
4位C#22点
5位Python21点
6位PHP20点
7位C++19点
8位C18点
9位TypeScript17点
10位Ruby16点
11位Swift15点
12位Objective-C14点
13位VB.NET13点
14位Assembly12点
15位R11点
16位Perl10点
17位VBA9点
18位Matlab8点
19位Go7点
20位Scala6点
21位Groovy5点
22位CoffeeScript4点
23位Visual Basic 63点
24位Lua2点
25位Haskell1点

生存バイアス

せっかくなので、生存バイアスも加味してみた。

生存バアイスは、 =ROUNDDOWN((2017-B2)/10,0) として、2017年から見て10年で1点とした。

年数がたっていれば、好きに加点して補正するという仕組みだ。

名前誕生生存バイアス補正
Visual Basic 61991年産まれ2点
CoffeeScript2009年産まれ0点
Hack2014年産まれ0点
VBA1993年産まれ2点
Lua1993年産まれ2点
Common Lisp1984年産まれ3点
Matlab1984年産まれ3点
Dart2011年産まれ0点
Erland1986年産まれ3点
Groovy2003年産まれ1点
VB.NET2001年産まれ1点
Perl2017年産まれ0点
Assembly1940年産まれ7点
Objective-C1984年産まれ3点
Julia2012年産まれ0点
Haskell1990年産まれ2点
F#2005年産まれ1点
R1996年産まれ2点
Scala2003年産まれ1点
Ruby1995年産まれ2点
Go2009年産まれ0点
C1972年産まれ4点
PHP1995年産まれ2点
C++1983年産まれ3点
Swift2014年産まれ0点
Java1995年産まれ2点
TypeScript2012年産まれ0点
SQL1974年産まれ4点
Python1991年産まれ2点
C#2000年産まれ1点
JavaScript1995年産まれ2点

wikipediaに掲載されていた日付をもとにした。

アセンブラは、それぞれのCPUごとに違うので、とりあえず一番古いコンピュータ(古代ギリシアのアレではない)の1940年としました。


生存バイアスを加味した、ガチで嫌われているランキング順

ランク名前嫌い好き生存バイアス差分
嫌われ1位Visual Basic 6-2532-20点
嫌われ2位CoffeeScript-2340-19点
嫌われ3位Hack-1600-16点
4位Dart-1300-13点
4位VBA-2492-13点
4位Lua-1722-13点
7位Common Lisp-1403-11点
8位Matlab-2183-10点
9位Groovy-1551-9点
9位Erland-1203-9点
11位Perl-18100-8点
11位VB.NET-22131-8点
13位Julia-600-6点
14位Objective-C-20143-3点
15位F#-201-1点
16位Haskell-3120点
16位Assembly-191270点
18位R-81125点
19位Scala0617点
19位Go0707点
21位Ruby-91629点
22位PHP-1120211点
23位C-1018412点
24位Swift015015点
25位TypeScript017017点
25位C++-519317点
27位Java-723218点
28位C#022123点
28位Python021223点
30位SQL-424424点
31JavaScript-125226点

集計に使ったexcel表はここからどーぞ。

http://rtilabs.rti-giken.jp/files/2017_03_31/a.xlsx

間違いがあったら、許してヒヤシンス

2017-03-24

ソース管理等を使った改ざん検知

最近、サイトに侵入して、

クレカのフォームを改ざんし、自サイトにカード番号を送信するといういたずらが流行っているようです。

一見正しく動いているプログラムが、実は改ざんされていることになかなか気が付きにくいものです。

運営されている会社も、クレジットカード会社から連絡があったりして発覚しているようです。

一方で、最近の開発環境はソース管理が導入されています。

デプロイツールも導入されているところがあるでしょう。

正しいソースコードがあるならば、それと比較して改ざんを簡単に検知できるのではないだろうか?

と、いうことで、ソース管理等を使った改ざん検知システムを作ってみた。

案1 ソース管理そのものを使った diff(ただしあまり安全ではない)

とても簡単な改ざん検知

例えば、SVN とかのソース管理で、サーバを管理している場合

(たぶん GITでも同じことができるはず)

#!/bin/sh
DIRGET_DIRECTORY="/var/www/vhost/example.com"
MAIL_TO="alert@example.com"
SUBJECT="[DIFF ERROR!]"
SCS_PROGRAM="svn"

#IS_ALIVE=`ps aux | grep "${SCS_PROGRAM} " | grep -v grep  | wc -l`
#if [ $IS_ALIVE -ge 1 ]; then
#	exit 1
#fi

cd $DIRGET_DIRECTORY
DF=`${SCS_PROGRAM} diff | wc -l`
if [ $DF -eq 0 ] ; then
	exit 0
fi

MAILTEMPFILE=`mktemp`
echo "To: ${MAIL_TO}"  >> $MAILTEMPFILE
echo "Subject: ${SUBJECT} ${HOSTNAME} ${DIRGET_DIRECTORY}"  >> $MAILTEMPFILE
echo "" >> $MAILTEMPFILE
echo "${SUBJECT} ${HOSTNAME} ${DIRGET_DIRECTORY}"  >> $MAILTEMPFILE
echo "-------------------------------------------" >> $MAILTEMPFILE
${SCS_PROGRAM} diff >> $MAILTEMPFILE

sendmail $MAIL_TO < $MAILTEMPFILE

/bin/rm $MAILTEMPFILE
exit 100

これで、改ざん者がサイトを改ざんしたら、

変更点が発生し、メールで通知を投げることが出来ます。

ただし、この方法では、本番のwebディレクトリにソース管理機能があるので、あまりよくありません。

まずは、apacheの設定等で、 .svn や .git などへのアクセスを遮断しないと危険です。

次に、逆流して侵入者に commitされないように、ユーザ権限を振らないといけないでしょう。

案2 deployツールを使った場合

deployツールをつかった場合はどうか?

1日1回ならともかく、10分に1回などの場合は、

毎回デプロイツールがチェックに行くのは現実的ではありません。

別のディレクトリにも同一内容をデプロイして、

そこと比較することが考えられます。

ただ、別のディレクトリにもデプロイできるか?というデプロイツールの制約の壁があります。

例えば、

本番
/var/www/vhost/example.com

デプロイしたときについでに取ったコピー
/var/backup/example.com

だったとすれば、以下のようなシェルスクリプトで、diffを使って比較できます。

#!/bin/sh
DIRGET_DIRECTORY="/var/www/vhost/example.com"
COPY_DIRECTORY="/var/backup/example.com"
MAIL_TO="alert@example.com"
SUBJECT="[DIFF ERROR!]"

#Ignore when deploying.
#IS_ALIVE=`ps aux | grep "rsync " | grep -v grep  | wc -l`
#if [ $IS_ALIVE -ge 1 ]; then
#	exit 1
#fi

LANG=C
DF=`diff -rq ${COPY_DIRECTORY} ${DIRGET_DIRECTORY} | grep '^Files' | wc -l`
if [ $DF -eq 0 ] ; then
	exit 0
fi

MAILTEMPFILE=`mktemp`
echo "To: ${MAIL_TO}"  >> $MAILTEMPFILE
echo "Subject: ${SUBJECT} ${HOSTNAME} ${DIRGET_DIRECTORY}"  >> $MAILTEMPFILE
echo "" >> $MAILTEMPFILE
echo "${SUBJECT} ${HOSTNAME} ${DIRGET_DIRECTORY}"  >> $MAILTEMPFILE
echo "-------------------------------------------" >> $MAILTEMPFILE
diff -rq ${COPY_DIRECTORY} ${DIRGET_DIRECTORY} | grep '^Files' >> $MAILTEMPFILE

sendmail $MAIL_TO < $MAILTEMPFILE

/bin/rm $MAILTEMPFILE
exit 100

diff | grep '^Files' と、しているのは、

webroot以下に本番にしか無いデータファイルがある場合を考慮してです。

アップロードされた画像とかがおいてあると、片方にしかないよという暴発がありえるので、このようにしています。

あとはcronで定期実行するようにすると、

改ざん検知ができるようになると思います。

どれくらいの頻度でチェックするべきかは、

負荷と相談してやるべきですね。


これで、万が一にもサイトが改ざんされたとしても、早期に気がつけるようになります。

早期に気がつけるということは、被害が拡大する前に即サイトを修正することもできるでしょう。

場合によって、改ざんした人が改ざんをしていろいろ試している時に、止められて被害ゼロということもあるかもしれません。

2017-02-18

フューチャーホームコントローラー(FHC)の複数台構成の実装の裏側

f:id:rti7743:20170218184003j:image

フューチャーホームコントローラー(FHC)の複数台構成について、裏側の実装をあまりに語っていないのでちょっと解説したいと思います。

https://rti-giken.jp/fhc/help/howto/multiroom.html


目指したのは、それぞれの部屋に置かれた端末がP2Pな関係で寄り添い通信して家全体のホームネットワークを自動で構築するというものです。

FHCには、webapiという機能があり、いわゆる共有キーのフレーズを使ってAPIを呼び出すことができます。

webapiは、 HTTP GETで要求を送り、返信は jsonで返ってくるシンプルなものです。

これを使えば自由に好きなアプリと連携できます。

https://rti-giken.jp/fhc/help/ref/setting_webapi.html

また、弊社サーバとhttps通信することで、リモートからでもWebAPIを呼び出せるようになっており、

外部webサービスと家の連携も可能になっています。

FHCの複数台連携は、このwebapiを利用する形で作られています。

具体的には、最初に相手を追加する時(信頼関係を結ばせる時)に、端末間でwebapiキーを交換します。

以後は、相手のwebapiキーを使ってそれぞれがそれぞれの機能を呼び出すというものです。

sshのキー認証みたいなものですね。

ただ、これは共有鍵なのでRSAとかに比べては弱いですが、ホームネットワークLAN内限定なのでまあ信頼しています。

もし、何か理由でキーを記録しているファイルが流出した場合、

webapiキーをリセットすれば問題ありません。

流失キーは即時無効になります。

そしてキーの変更はホームネットワークで自動適応されます。

ユーザは何も考えずにキーをリセットしてOKです。

機能としても、いろいろ頑張っていて、

1:Nの複数台とリンクできるし、

複数の部屋に置かれたFHC群へのアクセスもとても容易です。

信頼端末の信頼端末(友達友達)とも一度にコネクションできます。

自分<-->信頼端末(友達)<--->信頼端末の信頼端末(友達の友達)
自分<-->信頼端末(友達)で信頼関係を結ぶと、
自分<-->信頼端末の信頼端末(友達の友達)
友達の友達とも信頼関係を自動で結べます。

つまり、新しく部屋にFHCを設置したとしても、どこかの部屋においたFHCと信頼関係を結べば、新しく部屋に設置したFHCは、すべての部屋にアクセスできるというものです。

いちいち、すべての部屋へ信頼関係を手動で結ばせるのは手間ですからね。

信頼関係を結ぶには、自端末にログインでき、信頼関係を結びたい相手端末のIDとパスワードが必要です。

当然ながら、これらがわからないと信頼関係は結べません。

いたずらで侵入しようとしても無駄です。

正規に使うのは簡単でもイタズラは難しいを目指しています。

さらには、

DHCPで相手のIPが変わったとしても自動追従してネットワークを維持します。

webapiキーが変わっても同様です。

同時にすべての端末の電源が同時に切れて、相手のIPが変動しない限り追跡でき、

FHCのホームネットワークはそう簡単には破綻しません。

相手のIPが一度に全部変動しても追跡する機能も理論上は可能です。

ただ少し面倒なのでそこまでは作っていません。

以上が、フューチャーホームコントローラーの複数台対応です。

それぞれの部屋に置かれた端末がP2Pな関係で寄り添い通信して家全体のホームネットワークを自動で構築するというのを実現しました。

また、侵入者によるイタヅラもはねのける防御機能と、

ユーザの利便性を上げる裏方の機能があります。

あなたも、複数の部屋にFHCを置いて、家全体のホームネットワークを作ってみましょう。

https://rti-giken.jp/fhc/help/howto/multiroom.html

これが21世紀の新しい家の姿です。