コミケの共同購入支援用アプリを作った話、そして数年運用してみての感想とか。

はじめに

この記事は「ブログ力爆Age Advent Calendar 2017」の１３日目の記事です。

adventar.org

同期がやってるこのカレンダー、前年に引き続き今年も参加しました。　去年はVue.jsでSSR（サーバサイドレンダリング）する - Qiitaを書きました。

今年は何を書こうか悩みました。　結局、今年は技術的な物は研究室のアドベントカレンダーでやっているので、ネタ系を書くことに決めました。

コミケ

コミケの時期です。　夏から冬はほんと一瞬でやってきます。　私の場合、優先度が コミケ>>卒論 なので卒論はそっちのけでコミケの準備をしてたりします。

私は海鮮なのでサークル参加はしません。そのうち技術島で出せたらいいかなーなんて思ったりはしますがね。買うのに全力を出します。　年に２回だけ真面目になり、どうすれば可愛いけもみみ本とグッズを集められるのか考えてます。　

今年も可愛いけもみみ本がいっぱい欲しい。

コミケと共同購入

広い会場、ちょっと前から東7,8とかいう魔境も追加された中で、10時から11:30分くらい（この辺過ぎると買い逃し率が一気に上がる）までの1時間30分でお目当ての大半を回収して回るのはなかなか難しいものです。

地図を記憶し只ひたすら回る訳なんですが、ホール間移動をすると一気に効率が落ちます。　なので私は身内とちっちゃなグループを組んで上手い感じに回したりしています。

こういった共同購入のグループ中で問題になってくるのが

• 事前の購入希望の付き合わせと担当決め
• サークル回っている最中の情報交換
• 購入後の金銭の受け渡し

などです。

共同購入の支援アプリを作った

高校３年の冬か大学１年の夏の時に色々と大変だったので、支援アプリを作りました。　それ以後ちまちまと作り直したりしながらグループで利用しています。

仕様は、サーバ-クライアント構成のアンドロイドネイティブアプリです。

なんでアンドロイドネイティブかというと、グループにはiなんちゃらとかいう物を使っているアホはいないからです。

どんなものかというと、全員が書き込める買い物リストがあって、そこにサークル単位で担当ユーザを設定でき、購入情報や並んでいる際の状況等を書き込みます。 そのリストが全員で同期されるって感じの代物です。

ちょっと昔の頃のスクショが合ったので貼ります。

サークルリスト↓ 性癖バレしないようにサークル名とか隠したらよく分からなくなった gyazo.com

地図とか

gyazo.com

使い方は、

• 前日までに買い物リストに欲しいサークルと品を各自が書き込んで
• 前日の夜に担当を決定
• 当日は自分の担当だけのリストを表示させ、サークルを回り、購入したら購入済みのチェックを付ける
• 撤収時にリストから誰が誰にいくら払えば良いか算出して戦利品受け渡ししておしまい

こんな感じに使います。

誰の欲しいものを誰が買ったかがわかるので、撤収時にワンボタンで金銭計算ができます。

使っての感想

• 買い物中にLINEとか電話とかSkypeとかでひたすらどこ買った？買ってない？　をしなくて良くなった
• 紙にひたすら買い物リストをメモらなくて良くなった

こんな点がアプリ化でよくなりました。　まぁ当然か。　

これは導入してから気づいたんですが、

撤収時の料金計算が圧倒的に楽になって感動しました。

作る前は計算くらい終わった後だからのんびりやれば良いじゃんって考えだったのに、導入後はこれないと辛くなりました。 撤収時はみんな疲れてるから頭使いたくないんですね。　はやくおうち帰って本読みたいって。

最近の課題

使えば使うほど、無限に課題がでてくるもんです。　最近はこんなのに直面しています。

通信

これは重要な課題。　コミケ会場の通信が最悪。 基本的に通信はぶつぶつ切れることを想定していないといけません。　前々回の東７でほとんど回線が繋がらず、アプリが機能しなくなったことがあり、その際から通信の部分については特に力を入れているのですが、もっとやらないとだめだなーって。 今はキャッシュを使ったり、送信失敗時に極力ユーザの手を煩わせないようにしようと手を打っている程度です。

ちょっとぶっ飛びすぎですが、１００人を超える規模のグループであれば、各自のスマホのBlueToothを用いてメッシュネットワークを構築しP2P通信することでコミケ会場中で安定した通信が出来そうです。　こんなのできたらすごいなーって思います。

地図

会場地図が問題、　どうレンダリングすればパフォーマンスが落ちなくて、なおかつ簡単に扱えて、コミケの度に作り直す手間が減るんでしょうかね。 今はエクセル方眼紙で地図を作り、ちょっと加工したCSVを生成、そのCSVからWebViewにロードしてJSでテーブルを構築して使っています。　描画にCPUが遅いスマホだと２秒くらいかかるのが欠点です。　使い勝手＆開発しやすさはそこそこ良いのですが。。。

SNS同期

Circle.msやPixiv,Twitterとの同期を入れたいです。　Circle.msと連携すればサークル登録の手間が減少しますし、Twitterはサークルさんが完売報告を行うのでリアルタイム監視は重要です。

登録してあるサークルさんがつぶやいたり、2chのコミケスレに情報がでたらプッシュ通知とか流れるようにとかしたいです。

やれたらなーって言ってることをやる

一番重要な課題。 上に上げたような機能は、時間を掛ければ作れるので、やるかやらないかなんですが、ずっとやってない。　

よくない。　なのでやる気を出す方法を考えて実行しないといけない。　

さいご

長く使ってると色々と楽しいことがある

この機能を持つアプリを初めて作ったのは高校３だか、大学１年だかだと言いました。なので４年ほど（７，８回のコミケで）このアプリを使っていることになります。　

これまで何度か作り直しをしていて、すごく良いことを得たなって思うことがよくあります。

一番始めに作った実装は、サーバ側がJAVAで出来ていて、TCPコネクションをアンドロイド側と貼りそのストリームでJavaオブジェクトをシリアライズし流す形でデータ同期をしていました。 DBなんてものは存在しませんでした。　自分でロックを取りクライアントが送ってくる時間情報と照らし合わせサーバ側のオブジェクトを更新し、クライアントに応答していました。　（頭おかしい）

そんな状態の初版から、ぷよぐらみんぐを学んでいき、DBを利用したり、サーバ側はAPIとして構築するなど進化していきました。

またAndroidも元々ぐちゃぐちゃな実装だったのが、大学３年の夏のリプレイス時にMVP＋DDDという設計で固めることに成功し、良い感じに作ることが出来るようになりました。

こういう自分の成長が見られるアプリを持てているのはすごく良いことだなーと感じます。　就職においても長く１つのものを開発してきた経験は武器になりました。

今後は（去年から言っているんですが）Firebaseを使ったり、AndroidもアーキテクチャをGoogleが示したのでそれに乗っ取ったりなどしたいです。　最近はフロントの人であるのでReactNativeとかで組んでもみたいなーと。。。

C93対応さっさとやれ

急いでやります。

おしまい。　

後付け

「ブログ力爆Age Advent Calendar 2017」　適当にもふもふかくとかいう枠を取ったせいで昨日の方には変な期待をされてしまいましたが、このアプリでもふもふにゃんにゃんする同人誌を手に入れることが出来るのでそれほど違いはないだろうと自己完結しています。

アドベントカレンダーは明日はかったーくんが書くそうです。　弊研の誇る偉大なるスーパーハカーなのですごい記事を書いてくれるでしょう。　期待しています。　じゃあおやすみ。

なんかかっこいいGPUのはなし

今日したこと

起床ちゃれんじ失敗

— namazu (@namazu510) 2017年12月12日

早速起床チャレンジに失敗。　昼夜逆転しすぎててよくない。　９時頃に嫁に「起きないんですか〜？」って言われた気がするんだけど二度寝の誘惑には勝てなかった。 結果３年生とのミーティングに遅れるっていうよくないことをした。

明日はちゃんと起きたい。

大学に着いたらなんかPCパーツが届いていたのでPCを組んだりした。　GPUとかが来たんですが、なんかかっこよかったので今日はその記事でも書こうと思います。

GPUとか

GPUとそのおまけたち。　研究室では１２月頃で年度の発注を終えないといけないので、年度の予算を使い切るためにいろいろなものを買います。

今年研究室ではGPUを買いました。　機械学習とかするんでしょう。

買ったGPUはASUSのGTX1080Ti　ピカピカ光るやつです。　同期が発注書を書いたので私は型番を知りません。　これがなんかものすごく冷えるのでおすすめだそうです。

早速適当な研究室の共用ワークノードにぶっ刺してみました。

このマシンは研究室の誰でも使えるCPUマシンという位置づけだったのですが、GPUも刺さってしまったので機械学習も回せる強いマシンになってしまいました。 GPUのディスプレイ出力系には一切何も刺さっていない（保護プラグすら抜いていない）っていうのがなんかいいなって思いました。

このごっついGPUを挿して電源を入れたんですけど、ファンが回りませんでした。　どうやらこのGPUは高温にならないとファンが回らないらしいです。 少し負荷を掛けるとファンの１つが回るなんていう高度なファンコントロールがされていたりします。

なんかファンが止まっているのは仕事してないようでムカついたので、即刻cudaを入れてGPUベンチマーク掛けました。

そしたら

こんな感じでちゃんと回ってくれました。　よく冷えるっていうからホントなのかなーって温度を見ていたら最高で57度程度。　 　 他に持っているグラボは全力稼働させると大抵70度に到達するのですが、このGPUは70度到達しないのでこれはよく冷えるなーって。　すごいですね。　

それにしてもLinuxのやつでASUSのグラボのカラーコントロールとかできるんですかねぇ？　できるならせっかくだしきれいにしてもいいかもしれない。　私はオタクなので真っ青にしますけどね。

あまったパーツでマシン組んだ

PC組みたい３年生が組んでくれました。　組みにくいケースを渡しちゃってよくなかったなーって反省しています。　　GPU以外はおまけのようなパーツ構成ですがちゃんと動く。

この子はkubernetesの6代目のワーカーノードになる予定です。　

田胡研のk8sは私が勝手に増殖させたせいでかなりの化物スペックになりつつあります。　ここでもうひと頑張りして卒業までに成果を出したいところです。

どうでもいいはなし

PCパーツといっしょになんかでっかい曲面ディスプレイも届きました。　まぁ安物なんですけど。　ここ最近の研究室は仮想通貨の研究室になりつつあるのでチャートとか大量に表示してなんかかっこいい感じにしたい。 明日にでも適当なディスプレイを掻っ攫ってチャートを表示して遊ぼうと思います。　

10GbpsのL2スイッチが発注済みなのでそのうち届くのですがこれの配線を考えたりしていました。　今日だいぶ配線を調べて配線図に起こしたのでいいかんじの配線をしたいです。　調べていてわかったのは闇が深いということです。 NASのセットアップ（ファイルサーバの移行）も早めにやっておかないとなので忙しいはずなんだけどずっと遊んでるしよくない。

ボードゲームチャンネルとか仮想通貨チャンネルとかブログチャンネルとかSlackに追加されるし最近研究室が活発感を感じて楽しいです。　さっさと適当に卒論を書いて楽しく遊びたいです。

サーバの写真とかしか撮っていないんですけど、スマホカメラがゴミで嫌だなーって感じました。 ご立派なカメラを買う気は一切ないんですけど、なんかもうすこしちゃんとした写真がさくっと撮りたいです。

Java9の新機能をちょろっと触ってみた

はじめに

この記事は、私の所属する田胡研究室のアドベントカレンダー９日目の記事です。

adventar.org

Java9

Java9が９月にリリースされてから早３ヶ月。　私はJava7のコードを某所で今も書かされています。

StreamApiがないJavaとかマジやってらんね。　for文でリストの写像とかしなきゃいけないんですよ。　マジだるい。

さっさとJava9に置き換えろこの野郎という怒りをぶつけながらこの記事を書こうと思います。　

Java9で変わった大きな変更と、使えそうな典型をちょろっとしたコード共に紹介します。

JEP

Java9の新機能はJEPとして提案されOpenJDK開発コミュが対応しました。

http://openjdk.java.net/projects/jdk9/

ここにまとまってます。　この中でも私みたいなへなちょこJavaプログラマーに効きそうな機能はこんなところかな？

イケイケなJava9の機能

• moduleシステム導入
• jshellとかいうREPLツール導入
• StreamAPI強化！！

まぁほかにもJVMのロギングの対応とか、Unicode8とか、Http2とか、乱数ジェネの強化とか、SHA3とか、非推奨GCが出たり、ファイナライザ変更とか、LocalDateTime強化とか、AOTコンパイラツールとかいっぱいあるんで、好きな人はJEP読んで。

Moduleシステム

Javaに新しい構文が追加された。　拡張子が.javaなだけのJavaじゃないコード誕生。

これまでJava類似機能をパッケージという単位でまとめ、それらを圧縮ファイルにしてライブラリ(JAR)として提供していました。　

適当なjarファイルを落としてきて使うっていう便利な機能ですね。

これは便利なんですが課題がありました。

• 可視性の設定が十分でなく、ライブラリ内部の機能を公開してしまう
• ライブラリの依存性の定義がないため、不足ライブラリがあったら探し出して落とさなきゃいけない

こんなところ。　

jarを適当に落としてきて使ったら、依存関係ですぐに使えず、結局１０個くらいjarを探し出して入れたことがある人は少なくないと思います。 某所でもこの前教授が依存関係で嵌ってぬわーんってしていました。

これらがモジュールシステムで対処可能になりました。　新しいディレクティブが追加されまくって公開とか依存関係とかを定義できるようになっています。

すごいですねModule。

module jp.ac.teu.cloud.service {

}

こんな記法からmoduleの設定ができますよ。　どっかで今後この記法見ても？？？ってならないように気をつけないといけませんね。 ちゃんとした使い方はいろいろなところでそっちを参考に。。。

jshell

これ私みたいなへっぽこJavaプログラマーには良い機能では？ javaのインタプリタみたいなやつ　よくrubyとかpythonとかでやれるやつ。　弊研生はJavaのインタプリタつくりましたーーー！ってこのコードを全部提出して単位を貰うと良いよ。

gyazo.com

こんなもんです。

Javaは雰囲気でどんな値返ってくるかとかわかるから、試しにライブラリの関数呼んでみるみたいなことは、需要がそんなあるわけじゃない気がするんだけど。。。　 やろうとしたとき一々クラスファイル書かなくてよくなったのは便利！！

gyazo.com

講義とかでちょろっと見せるのに使えるかも知れませんね。　 まぁ弊学では、皆にJavaを教えたはずなのに、課題でラムダ書いたら大半が理解できなくて、おまけに老害みたいなこと言い始めたSA・TAまでいたのであれでしょうけど。。。。

StreamAPI強化

あいつがもっと強くなった。 　 streamapiというとこいつとか。

List.of(1,2,3,4).forEach(System.out::println)

サンプルがこれかって？　便利じゃないですか。　

あList.of()っていうのはJava９で追加された子です。　ついにこいつができた！。　今までよくstatic finalなリストやマップに、staticイニシャライザで値を突っ込んで、よく分かってない人からなんですかこの構文？って聞かれたことがある人は多いはず。

private static final List<String> hogeMap = new ArrayList<>(); static {
  hogeMap.add("にゃーん");
}

こんな無駄なことをしなくてもいい。

List<Integer> lst = new ArrayList<>() {
   public ArrayList() {
     super();
     add(1);
     add(2);
     add(3);
     add(4);
     return;
   }
}

こういうのとかもしなくていい。 あ、上のコード、Java8だとArrayListのあとのジェネリクス省略でコンパイル通らねーぞ＾＿＾と思った人。　Java9だと匿名クラスのジェネリクスを上手い感じにしてくれるのでいけます。

ofメソッド　便利なんですが注意点が一つ、以前Arrayからのofでリストつくるとかしてた人なら分かると思うけど、できあがるのは不変リストなので、変えたい場合はこれでできた値を新しいリストのインスタンスにつっこんで使いましょう。

StreamAPI自体としては、streamインターフェースにいくつか便利なのが追加されました。　takeWhile(Predicate<? super T>)とかです。　意外と便利？

個人的にはCollectersの拡張がありがたいです。filterlingとか。　終端でフィルタを噛ませられるようになったよ。

さいご

Javaは８からの進化がいいですね。　私は進化とレガシーさの良い感じのバランスが好きです。　でも某所のJava7は無理。　マジで無理。　 イケイケなひとが全部Java9にしておいてくれないかなーって。　まぁ某所がJava7のままなのは私が手を付けなかったせいでもあるので、あまり文句は言えないんですけどね。

StreamAPIの新規追加メソッドの全サンプルとか載せたかったけどちょっと日和ってしまいました、ごめんなさい。　

Javaをメインで書くことは今後減るんだろうけどずっと追い続けていきたいなーって記事書いてて思いました。

明日の田胡研アドベントカレンダーは期待の３年生のfubukiくんです。　ご期待下さい。

javascriptとYAML

今日したこと

某所のフロントでyamlを使ってとあるオブジェクトを構築したりしているのですが、ちょっと高度なyamlの機能を使いたくなった。　

まだやったことがなかったyamlの機能をjsで使ったら想像以上に使えて感動したので今日はその知見でも。

yamlのアンカー

yamlは参照が使えますね。 この点でyamlは木構造以外のデータ構造をシンプルに表現できるので強いです。

sample.yaml

pan:
  &item1
  name: item1
  price: 100
pon:
  *item1
pen:
  *item1

こんな感じでアンカーをつけて参照すると pen,pon,penそれぞれが同じnameとpriceを参照するようになります。

jsonとかだとこれができなくて色々と辛いことがあるけどyamlはできる！！　すごい！！

javascriptでyaml

www.npmjs.com

これを使うことでyamlからパース＆yamlにシリアライズが可能です。 Loadがパース,Dumpがシリアライズです。　

yaml = require('js-yaml')
fs = require('fs')

try {
    var doc = yaml.safeLoad(fs.readFileSync('sample.yaml'))
    console.log(doc)

    doc.pon.price = 200
    console.log(doc)

    var dump = yaml.safeDump(doc)
    console.log(dump)
} catch(e) {
    console.log(e)
}

前述のyamlをパースして 参照先のpriceを更新、オブジェクトをシリアライズします。

実行する

{ pan: { name: 'item1', price: 100 },
  pon: { name: 'item1', price: 100 },
  pen: { name: 'item1', price: 100 } }

{ pan: { name: 'item1', price: 200 },
  pon: { name: 'item1', price: 200 },
  pen: { name: 'item1', price: 200 } }

pan: &ref_0
  name: item1
  price: 200
pon: *ref_0
pen: *ref_0

参照になってるからpriceが全部同じところ参照してて更新すると全部変わる！ シリアライズもちゃんと参照を維持してくれる。

公式のデモ

nodeca.github.io

どんなことできるか一覧のデモです。　yamlの機能（知ってる限りは）全部使える感じ。　ファンクションとかも行ける　すごい。

in webpack

github.com

この辺を使うのがいいでしょう。

ただ　yamlfile => yaml-loader => json-loader というつながりで読み込むやつなのでyamlがJSON相当のものしか扱えないのが残念です。webpackでyamlの高機能使いたいときはtextで入れて置いて実行時パースかな?

javascript object marshal?

yaml強いのでそこそこに使えそう。　ただJSON.stringifyのが速いわけだからパフォーマンス的には当然難しい。　頻度が低いなら問題なくいい感じに使えるかも。

Linuxでログインを検出して通知するちょっとしたコード

きょうしたこと

サーバでログインしたらなんかSlackに通知とか来るようにしてこの共用鯖どれくらい使われてるのかなーとか測ろうと思いました。 適当なコピーすれば動くサンプルあるだろーとおもったらすぐには見つからなかった。　なのでシェルスクリプト書けない無能なりにちょっと頑張って書いた。

Linuxのログイン履歴

ログイン履歴は　last コマンドで見れます　lastlogコマンドを使うともう少しちゃんと出ます. 新しくログインをするとlastコマンドの出力結果に時間とかユーザ名とかIPが出てくるのでこれを使えばログイン検出できそうです。

ログイン検出してなんか走らせる汎用コード

lastコマンドをちょろっとつかって作った結果

#!/bin/bash
set -eu

last | sed -n 1p | awk '{print $1,$4,$5,$6,$7}'> login.log
while :
do
# loginログ最新を漁る
last | sed -n 1p | awk '{print $1,$4,$5,$6,$7}' > latest.log
if diff -q login.log latest.log >/dev/null ; then
    # 新規ログインがない
    : 
else
    # 新規ログインがある
    echo "`hostname`で新しいログイン `cat latest.log`"
　# ここから通知とかのスクリプト叩く
　mv latest.log login.log
fi
sleep 10

done

こんな感じで行けました。　シェルスクリプト力の無さがコメントとかににじみ出ていますね。　一応これでログインが行われるとコンソールに出力されます。 そういえば初めてawkとか使った。　知見が増えました。　色々便利な使い方をこれから知っていきたいです。

このコードを使えばあとは

qiita.com

こういう先人の知恵を参考にさせていただいてスクリプトからSlackに飛ばせばOKです。

どうでもいい話

某所のサービスでNginxの設定変更が必要で色々とやってました。　実際にはk8sのNginxIngressControllerなんですが。

設定を変更してもなんかうまく動かなくてなんでー？？？って机バンバンしたり研究室の中をぐるぐる回ったりしていました。

結局

Nginxの変更適用されなくて？？？？ってしてたら問題引き起こしてるのはその上の段のNginxだったOTZ。。。

— namazu (@namazu510) 2017年12月6日

こういうアホみたいな原因でした。　ちゃんと上段も設定したらうまく行きました。　全体を把握してから取り掛からないと時間がかかることがあるよっていういい知見を得ました。

田胡研とジェンガとXXX

はじめに

この記事は、私の所属する研究室、田胡研究室のアドベントカレンダー５日目の記事です。

adventar.org

登録したときからしょうもないことを書くと宣言していたとおり、今日はネタ記事を書こうと思います。

今日は田胡研でみんなでよく遊んでいるジェンガについての記事を書きます。

田胡研ジェンガルール

普通のルール

箱に書いてあるジェンガの一般ルールは以下の通りです。

• サイコロを振る
• サイコロの出目に指定された色のブロックを山から抜きます。　もし★の出目であれば２ブロックを抜く。
• ブロックを上に積む、ブロックは一番面積の広い面を接地させるように置かなければならない、また１段に３つブロックが置かれ埋まるまで次の段においてはいけない

山を途中で崩した人が負け。

これが普通のジェンガのルールです。

田胡研ルール

田胡研では変則ルールが適用されており、

• ブロックを積む際はどの面を接地させてもよい。　＝＞　つまり縦に積んだりしてもよい
• 縦に積むなど変な積み方が始まった場合、それ以後はその積まれた位置より上に置かなければいけない。

というルールが適用されています。　つまり。。。

こんなことになります。　＞＿＜；　

変な積み方をしてもいいというルールなので、普通に置くこともできます。　しかし、なぜか頭のおかしい人が縦に積み始め「勝負に出る。」とか「ここで潰す。」とか言い出しておかしなことになります。　

これまでまともなジェンガは２，３回しかやっていません。

負けるとこうなる

ちなみに弊研では×ゲームと言えばデスソースと化しており、デスソースの一番辛いやつ10g入のカップ麺をすでに三回ほど食べています

— ううたろ (@uutarou10) 2017年12月4日

某所で既にどうなるか公開されていましたが、煽るのが大好きな頭のおかしい人のせいでデスソースをかけてカップ麺を食べるなんていうのが日常になっています。　こんな感じ。

gyazo.com

gyazo.com

gyazo.com

デスソースが届く前はそこそこ辛いカップ麺を食べるくらいだったのですが、、、デスソースが来てからいっきにきつくなって来た。　今ではほんと負けたくない。。。　誰だデスソース買ったやつ？？？

辛いのを食べて苦しんで暴れているところ、を誰かが「喜んでる。」なんて煽りだしたりして、最近はお先真っ暗感のある戦いになってる。　そのうちみんなデスソースで死ぬ。

田胡研ジェンガ攻略

負けたくないのでちょっと攻略法を考えました。

ジェンガの重さ

知らない人がたまにいるのですが、ジェンガの重さはそれぞれ違います。　全部均等だと重さがうまく偏らなくてつまらないゲームになってしまうので、そうならないようにある程度バラしてあるそうです。 実際の重さの変化幅とどれくらい分布しているのか調べました。

測定方法

このような感じに重さをそれぞれ測ります。　研究室にはしょぼい秤しかなかったので、１ｇ単位ですが。。。

全部測って重さ順に並べるとこんな感じ

左側が14ｇ　右が21gです。　最大で7gの質量差があることがわかります。

数値分布を詳細にグラフにすると

gyazo.com

こんな感じになります。　秤が１ｇ単位でしか測れないので変な感じのグラフになっていますが、どうやらジェンガは18gぐらいが一番多く存在しそこから離れるほど数が少なくなるようです。　もっと大量に制度測れば分布関数とか出せそう。

どうすべきか。

ジェンガの重さに差があるため、高さがやばくなってきたら、軽いジェンガを上においてお茶を濁すとか、初めのうちは重いジェンガを置いて安定させるとかすると長くジェンガが続きそうです。

ジェンガの台

田胡研ジェンガいつからあるのかわからない不安定な台の上

gyazo.com

でやることになっています。　この台、なんか手を触れると揺れます＞＿＜。　よく揺れることはみんな知っているのですが、この台、明らかに傾いています。

どれだけ傾いているか測りました。　その結果。　上の写真の奥から手前側の間４５cmで0.6cmくらい下がっています。　つまり、0.6度位傾いていることがわかりました。

どうすべきか。

まぁどれだけ傾いているかわかったところであまり参考になりませんが、７段目から先を積むときに重心を見抜く１つのポイントにはなるでしょう。

戦略とか

ジェンガは積極的に他人に倒させていきましょう。 田胡研ジェンガにおいて抜くのは比較的容易なので、詰みにくさから誰を潰すか狙うことが出来ます。　サイコロを降るときに机から落としてしまうと確定で２個を積むことになるというルールがあるので、５個積まれた状態で、わざとサイコロを落とし２つブロックを積むと隣の人は８段目を積むことになるので大抵殺せます。

段を置く毎にどんどん難しくなっていくのですが、大体無事に積める確率は

• １〜5 段目 98%置ける
• 6段目 90％置ける
• 7段目 65%置ける
• 8段目 30%置ける
• 9段目 10%置ける
• 10段超え　未知の領域

こんなかんじなので参考にするといいでしょう。

あと倒したらデスソースなのでそのプレッシャーを与えると手がみんな震えます。　煽っていきましょう。

攻略法はこんなところ。　みんなで憎きアイツにデスソースカップ麺を喰わせよう！！

そういえばデスソースは使いきったんだけどさ....

罰ゲームでデスソース使いまくってたら、使いきって。

gyazo.com

即座に、

gyazo.com

＞＿＜；

さいご

弊研では昔、縦に１１段まではジェンガが積まれたことがあるそうです。　なので

tg研アドベントカレンダーではジェンガ１１段積み上げて写真をあげたい

— namazu (@namazu510) 2017年12月3日

これをしたかったのですが、３０分くらい一人でやっていても９段が限度でした。　ジェンガしてると無限に時間がなくなってタスク終わらないので気をつけましょう。

アドベントカレンダー明日は、３年のsekunがイケイケな記事を書いてくれるそうです。　多分明日は技術ネタです。　素晴らしい記事が来ることでしょう。　それでは。

Linuxで端末を痛くする

今日したこと

今日はなにもしてない。　よくないなーって。　 NOT MY FAILT　っていうテーブルボードゲームがあるのですが、それを研究室のみんなで鍋を食べながらやっていました。

最近していたこととして、ひたすらLinux端末のターミナルエミュレータの背景画像をいい感じにするということをしていたので、今回はその知見でも書いておこうと思います。

痛くできるターミナルエミュレータ

まず簡単に背景画像を設定できるエミュレータでないと痛くできません。

ターミナルエミュレータは色々あります、真っ先に思い浮かぶのはGNOMEに入ってるGNOMETerminalです。　しかし、いつのバージョンからか背景画像設定のメニューがなくなり、背景画像を設定できません。　ネットの例だとこれで設定するメニューがあるのですが、私のバージョンでは設定項目が消えていて弄れませんでした。

こまった。。。。　ということでいくつか見た感じで簡単に設定できるエミュレータを探しました。　やってみた知見として

• Konsole
• Guake

は設定できます。　ただしKonsoleは背景画像は指定できるものの透明度設定ができないので、背景画像を自分で編集して、黒いマスクを画像にかけてその画像を使うようにしないと大変です。

Guakeはいい感じです。　背景画像の選択とその画像の透過率を設定できます。　キーでドロップダウンしてくるのとか多タブが簡単に使えるとかいい感じだったので、私はこれを使うことにしました。　今はATOKから離れてしまったので使っていない無変換キーを押すことでターミナルが出てくるように設定しています。　これはとても便利です。

背景画像チョイス

背景画像を探し求めて２，３日くらいだらだらしていました。　今でももう少しいい感じのがないかなーって探しています。 背景画像を選ぶ際の個人的なポイントについて知見を書いておこうと思います。（誰得すぎる）

1 R18はやめる

人に見せられなくなるのもそうですが、なんか見ていると疲れてきます。　肌色成分が多すぎて落ち着かなくなる。　抜きたくなるとかそういうのはないんですが、なんかキツイ。　例えると、暗い部屋で輝度高いディスプレイを見たときのような疲れが出てきます。　なのでR18のどぎついのはやめましょう。

2 背景ががっつり書き込んである画像はやめる

背景ががっつり書いてある神な画像は集中できなくなります。　画像透過度を抑えることでこれを防げますが、キャラがあまり見えなくなってテンションが下がってしまいます。　シンプルなやつをチョイスするのがいいと思います。

3 キャラを左サイドに配置した画像を使う　

これが重要です、コンソールという特性上（Guakeでは特に）画面横半分だけとかで作業することが多くなります。　このとき画像のど真ん中にキャラがいると真っ二つにされテンションがだだ下がりします。　これを避けるために常にターミナルを全画面表示するという手がありますが、作業効率が落ちるのでやめましょう。　半分だけ表示した状態でもキャラが見えるように背景画像の左サイドにキャラのメイン部分が収まっていることが望ましいです。　画面４分の１状態になったときでもいい感じに出る画像だと最高です。

4 微妙にエロい画像にしとく

ターミナルを開いたときに幸せな感じになる画像にしておかないと、やる気が下がります。　がっつりエロいとあまりいい感じにならないと上に書きましたが、まったく露出とか誘い要素がない画像を使うと個人的にターミナル開いたときに作業感が出てやる気を喪失します。　なのでそこそこ露出が高いくらいのレベルにしておくのがいいと思います。　画像透過度でキツさは抑えられるので他人に見せても（個人的に）大丈夫だと思います。

でどんなのにしたの？

こんなかんじ。　ヴァンパイアちゃん。　かわいい。 横長にすると右の方にきつねちゃんもでてくる。　かわいい。

おしまい。　明日は田胡研アドベントカレンダーにしょうもないジェンガ攻略法とかを書く。