今年はあまりゲームが出来ない年でしたが、今年購入して、とても良かったゲームをまとめます。

• Nier Automata
• ゼルダ ブレスオブザワイルド
• DQ11
• ファイアーエムブレム無双
• アズールレーン
• ドラクエヒーローズ 1,2

Nier Automata

Nierは今まで遊んだゲームの中で3本の指に入るくらいとても良かったです。前作を買ってからヨコオワールドに魅了されました。世界観と音楽がとても素晴らしいのですが、今作は開発がプラチナゲームズという事もあってアクションゲームとしても素晴らしい作品です。
とにかくプレイして欲しい。

ゼルダ ブレスオブザワイルド

ゼルダは言うまでも無いですね。
Switchは発売日に購入できましたが、実はNierが終わっていなかったので暫くやっていませんでした。あと最初にドラクエヒーローズを始めたのでゼルダは暫くお蔵入りになっていました。開発者インタビューが公開されて、CEDECで開発話を聞いて、やべえなと思いました。今まで個人の職人芸に強く頼っていた部分が、理論化されての大規模開発という事で、色々と衝撃を受けました。

DQ11

DQ11は3DSでやりました。
2Dと3DがSyncして動いていて、なんて変態なんだと思ったけどテクニカルディレクターが紙山さんという事で納得。私はループ系のストーリーが好きなので、FFCCやNierは大好物なのですが、このDQ11もそうだったのでとても良かったです。ストーリーにウルウルきたのは久しぶりでした。ちょっと長かったので最後はダレてしまったけども。

ファイアーエムブレム無双

FE無双。無双ゲームが好きというバイアスはありますが、FE無双はコラボ無双の中で抜群の出来でした。
まだ遊び尽くしていないので今年も暫くは遊ぶと思います。

ファイアーエムブレムな。商材名間違う人多すぎる。

アズールレーン

アズールレーンはスマホゲームですが、艦これのシューティングゲームという感じです。
崩壊学園がよく出来ていると思っていたのですが、このゲームもそれの関係者のようですね。ゲームとして普通に面白いです。これも暫くは遊び続けると思います。ちょっと頑張ってランキングは19位まで入りました(o゜▽゜)

Steamのゲームもちょこちょこ遊んでいたり、3DSで不思議のダンジョンとかもやっていました。

2018年、期待しているゲームはオープンワールドの三国無双8、エースコンバット7です!!

前置き

• 全ての会社、プロジェクトにおいて前提条件と置かれている状況は異なります。これはあくまでも自分が体験した1つの例ですので、自分の所はそうでは無いというのであれば、それはそうなのでしょう。
• あるベンチャーにおいては、ビジネスの速度こそが重要である。

ある組織において共通の目的を持っている場合、肩書きというのは何に重きを置いて問題解決していくかを示すものであり、ソフトウェアエンジニアはエンジニアリングに重きを置いて目的を達成するロールである。ただし、共通の目的を達成するというミッションが前提になっている事を忘れてはいけない。
時として「俺(私)は目的を達成するためにXXをやろうとしているのにそれを阻害する行動を取られる」と文句を垂れる人間が居ますが、それはその手段が相当な悪手か、そもそも共通の目的を共有出来ていないのが原因です。

本題

さて、タイトルに書いた、速度を優先する事で品質が疎かになるのは正か否か。これは端的に言えば程度問題なので正でもあって否でもある。
ベンチャーにおいて、スケジュールが十分に妥当であること（まだ何も決まっていないが明日までに〇〇を出したいとかいうアホな事案で無ければ）を前提にすれば、ビジネスの速度にスケジュールが間に合わないのは技術力不足であると私は考えています。

スケジュールがタイトな場合に取る選択肢は幾つかあります。

1. スケジュールをずらす
2. 機能を削ぎ落とし、段階的なリリースにする
3. ソフトウェアの品質を落とす

最初に書いた前提より、1は無し。通常は2を選択する事が多いが、削ぎ落とすものが無い場合は3を選択する事になります。

ただし、こんな事をしなくても出来る人は出来てしまうものです。それはその人が超人だから出来ているのでは無く、日々の積み重ねがあるから実現できるのです。
日々の積み重ねとは、何かあった時に普段からモニタリングしていたり、ある程度予測して準備したり、仕組みを用意しておいたりする事です。何かの案件を小耳に挟んだときに、自分は関係無いと思わずに当事者意識を持って準備をする事です。

Productionに出しても良い品質を80点以上とします。
時として間に合わない時は管理職判断で60点でも良しとする事はあります、ビジネスを優先した結果そうする事もあるでしょう。ですが普段から60点や40点の仕事をする人間に対して40点でも良しとするのはナンセンスですし、絶対値基準として40点でリリースという事自体がナンセンスです。

良く着地優先なのでという理由でテストを一切書いていなかったり、そもそも筋が悪いプログラムのPullRequestがあります。普通にやっても人によっては余裕で着地出来る案件を、着地優先という理由で20点や40点で着地させようとするのは、ソフトウェアエンジニアとしての職務を全う出来ていない事になります。実力不足、技術力不足である事をスケジュールの問題に挿げ替えているだけです。
それを着地優先だったので良しとする文化は、ソフトウェアエンジニアとしての成長を妨げる事になり、能力の凹凸がより歪になり、延いてはエース/シニアエンジニアが尻拭いをする時間に追われ、組織としてスケールできなくなる構図が出来上がります。
これで辞めていった優秀な人材を何人も知っていますし、実際に見ています。

また、1カ所に権限を集中させるとミスジャッジが発生した時、議論の余地が無くなり、さらには議論をしても意味が無くなるので、そもそも議論をしなくなり、健全な体制にはなりません。能力と権限を対等に分散させれば上手くいくとは限りませんが、少なくとも同じ方向を向いている限りは上手くいかなかった例を知りませんし、集中させる事によって悪いことが起きた事例を何個も知っています。そして、また後者が発生したかと思う度に、権限が集中していると介入余地がないので改善する余地が無く、疲弊していくわけです。

リスクテイクについて

60点で出す時はリスクが存在します。そのリスクをどのように扱うのかは大事な事です。

レースを例に挙げると、各種モニタリング、ガードレールやタイヤバリア、医療チームや救急車の手配の準備が万端であるからリスクを冒せるのです。
エンジニアリングも同様で、こういった何かあったら分かるようにする、何か起きたらそれに対処できるように準備しておく、といった保険があるからリスクを取れるのであって、保険をかけないやり方はただの無謀である。

こういった日々の積み重ねによって品質は成り立っており、何かあった時になんとか出来るように準備を積み重ねているのです。

原則について

金曜日にデプロイするのは禁止という原則が多くの会社にはあります。正確には、休みの前に初めて動くコードが無いことにするです。
これに対して文句を言う人が居ます。それだと着地出来ないとか、新機能をガンガン投入出来ないとか。プロジェクトのフェーズにもよりますが、あくまでも原則なので別に守らなくても良いのです。
ただし何故このルールが必要なのか、原理を理解しないで文句を言うのは筋が悪いです。

ルールが出来るのには何かしらの事象が蔓延っているからです。
金曜日のデプロイをする人間が、いつも40点や60点のプログラムを出しておりリリースの度にトラブルが発生させ、普段からアラートを見ている訳では無く、週末にアラートが上がっても他の人が対応しており月曜日になっても特に言及する事は無い。きちんとしたポストモーテム(振り返り)はせずに何回も同じ事を繰り返し、場合によっては不具合が発生している事に数週間気が付いていない。

このように何かあっても率先して自力で対処する事は出来ない（しない）人間に、金曜日デプロイを許可できますか? という話なのです。

何かあったら真っ先に対処しますという言葉も、普段の行動により信用力が伴っていないので、全く信用する事が出来ませんし、事実何かあってもその人間が対応しているのを見たことは殆どありません。真っ先に対応するという言葉だけでオンコールのローテーションに加わったりしているわけでもないのですから。

この原理を破っても良い人間も居ます。上記に挙げた行動とは逆で、スケジュールを殆ど守っており、品質も高くそもそもトラブルが殆ど発生していない。普段から真っ先にトラブルシュートをこなしている人間であれば、「何かあったら自分が対処するのでリスクを承知で反映します」という言葉にも信用が持てます。

このようにルールが出来るのには理由があり、文句を言う人間というのはそのルールが出来た原因である事が多いのです。しかしながら原理を理解していないため、自分で自分の首を絞めている事に自ら気づいておらず、どうでも良いルールが追加され、真面目にやっている人に迷惑をかけるのです。

大事な事は

最初から上手く出来る人はいません。何回か失敗を繰り返しながら成長していくものです。
何回も失敗している人は、振り返りが出来ていないのです。振り返りをやっても形だけでやっており根本原因を精神論で片付けている事が殆どです。

この様な状況に遭遇したとき、次からはどうするかを考え、対策を講じる事が大切です。何か失敗をしたのであれば精神論ではなく仕組みを持って解決していく必要があります。単純に実力が足りていないのであれば実力を付けるしかありません。
次どうするかを考える事を蔑ろにする組織/人間は、同じ過ちをひたすら繰り返し、信用を無くすだけではなく、周りの人間を疲弊させます。

最終的には、意識の高い人間やエース/シニア級の人材を何人も流出させる事に繋がっているのです。

まとめ

集中した権力の暴走は、ある領域の今までの仕事/成果/信念を踏みにじる行為に捉えられ、完全にやる気を無くします。

今月ジョギングを開始しましたが、数週間で膝を壊しました😨
どれくらい酷かったかというと、一時は歩くことすら困難でした。膝が常に熱を持っていて、何もしなくても非常に痛みを感じてしまい、それを庇って歩くことでさらに悪化してしまうという状況でした。両膝共に痛かったのですが特に右膝が痛く、歩く度に体重がかかり激痛が走る状態でした。
会社に行くのすら辛いのでタクシーを使いました。

治療について、まず鍼治療をしました & そこでマッサージをしてもらいました。
少しだけ痛みは和らぎましたが、そこで言われたことは水が溜まっていることと、病院に行きましょうという事でした。

次に整形外科に行きました。お薬と湿布を貰い、アイシングの仕方を教えて貰いました。またリハビリのためのマッサージを受けるととても楽になりました。マッサージとストレッチによって固くなってしまった筋肉をほぐして貰いました。それから毎日、マッサージと細かい頻度でアイシング、痛み止めの薬も飲んでみると、少しずつ良くなりました。一度に一気にやったのでどれが効いたのかわかりませんし、もしかしたら自然治癒だったのかもしれません。

個人的には湿布がとても良かったと思います。
湿布はお父さんが気安めのために貼る物というイメージでしたが、きちんとしたお薬だったんですね。

スポーツ経験者やお医者さんにヒアリングをし、次の事が原因である事がわかりました。

• 準備運動が足りなかった
  • 特に柔軟が足りなかった
  • 体を十分に温めてから運動するべきだった
• 運動後のケアが十分でなかった
  • きちんとアイシングをしていなかった

まだリハビリ中で全然完治していませんが、次スポーツする時はジョギングではなくアクアエクササイズにしようと思います。このあたりのジムが気になってます。

• http://www.sportsoasis.co.jp/sh53/
• http://www.sportsoasis.co.jp/sh58/

ApacheLoggenを更新しました。
ApacheLoggenはApache形式のダミーログを出力するやつです。

limit引数に2を指定すると3件出力されるというoff-by-oneな不具合の修正です。

それはそれとして、apacheなんてずっと触っていないのでnginxのログを追加しましょうかね.

ここは自分用のメモ

手元でテストする時。不通に実行するとインストール済みのgemsを見てしまうので。

手元で実行する時

bundle exec ruby lib/apache-loggen.rb

Gemsへのリリースの方法

curl -u [MY-MAIL-ADDR] https://rubygems.org/api/v1/api_key.yaml > ~/.gem/credentials; chmod 0600 ~/.gem/credentials

rake release

最近、Facebookのインスタント記事(IA)に関する調査をしています。

自分のブログをIAに対応してみたり、サンプルサイトを作っては審査申請をしてみたり。やってみて思った事は、FBは本当にこれを普及させたいのだろうか 😞

RSSで連携させると、インポートされる記事がすごいひどいことになる。そして審査で落とされる。公式の方法で連携させて微妙な結果が出力される上に審査で落とされる。そして結局手でIA用のHTMLを微妙なエディタで手打ちをするという仕打ち。こういうタグ表記はNGというものが多すぎて、成果に対する労力が見合わないぜ..

個人のサイトでここまで大変でストレスが凄いのだから、各媒体が手を出せないのも理解できる。実際に触ってみて分かる。

とてもつらい

再審査のボタンが押せない

記事の中の、op-modifiedを次のように、現在の時間に近しい値にしないとダメな模様。
はいはい、これも手作業で更新しましたよ😰

<time class="op-modified" datetime="2017-11-05T00:00:01-07:00">2017-11-05T00:00:01-07:00</time>

参考

• https://stackoverflow.com/questions/36618183/facebook-instant-articles-cant-enable-the-submit-for-review-button-its-alw

もともとBlogをGithub Pagesでやっていましたが、HTTPS化するのにCloudFlare使うのもなー、証明書の更新も面倒だなと思って躊躇していました。

証明書の更新だったらAWSのACM使えば無料だし、Acceptさえすれば自動で更新されていくし便利じゃん！と思い、S3とCloudFrontの設定をしましたが、サブディレクトリのindex.htmlが上手く解決できませんでした。
最初はS3をPrivate化して、CloudFrontからのアクセスに成功。しかし、index.htmlが解決できないので、S3をpublicにして必要な設定を入れてみても、どうも上手くいかない。

もやもやしていたところ、Netlifyの存在を教えて貰いました。

なにこれ、簡単すぎる!!

15分もあれば、諸々設定終わります。証明書もLet’s Encryptとボタン1つ押すだけで、自動で証明書が作られて自動更新されていきます。

とはいえ、いくつかハマったところがあったのでメモを残しておきます。

Let’s Encryptの設定でハマった

最初はcustom domainを適当な値にして確認していて(例:test1.orz.at)、それで証明書の設定を入れた後に、blog.orz.atに名前を変更したら、証明書の更新はどこからも変更できませんでした。なので、blog.orz.atでアクセスしてもtest1.orz.atの証明書が使われてしまうことに。

証明書を消すことも出来ないので、サイトそのものの定義を削除して、作り直しました。

(DNSの設定はNetlify管轄にしないで、CNAME指定でやってました)

Redirectの設定

{site}.netlify.comでアクセスしたらblog.orz.atに飛ばしたい。
Origin的なサイトが見えちゃうと、コピーサイトに見えそうだし。そもそも複数のドメインからアクセスできちゃうの嫌。

ここを見ると、redirectの設定ができます。テストはここで確認できます。
というわけで、以下の設定を追加。

http://tamtam180-blog.netlify.com/* https://blog.orz.at/:splat 301!
https://tamtam180-blog.netlify.com/* https://blog.orz.at/:splat 301!

そして、今もハマってる最中。
Hexoの設定でgenerateした時に、_redirectsが対象外になっていました。設定ファイルに次を追加。参考

include:
  - _redirects

できた

custom domainへ移動するようになりました。

$ curl -I "https://tamtam180-blog.netlify.com/"
HTTP/1.1 301 Moved Permanently
Cache-Control: public, max-age=0, must-revalidate
Content-Length: 35
Content-Type: text/plain; charset=utf-8
Date: Sun, 29 Oct 2017 15:32:39 GMT
Location: https://blog.orz.at/
Age: 1
Connection: keep-alive
Server: Netlify

こんなコードで実験。
普通に考えると、Parallel()はJVM内で共通のPOOLを使い、使えない場合はcaller threadを使うようになる。
現に、ExecutorServiceを使う場合、そのような(commonのforkjoinとcaller threadを使う)挙動になる。

なのでparallel().foreachの中で重い処理を書くと全体に影響が出る。(もちろんcaller threadで実行されので処理が止まってしまうわけでは無い)

しかしながら、ForkJoinPoolを使った場合、全てのスレッドがForkJoinPoolで実行されるのである。なぜ共通のPoolが使われないのか？

//ExecutorService forkJoinPool = Executors.newFixedThreadPool(2);
ForkJoinPool forkJoinPool = new ForkJoinPool(2);
forkJoinPool.execute(() -> {
  Arrays.stream(new int[]{ 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20 })
  .parallel()
  .forEach(ii -> {
    int r = ThreadLocalRandom.current().nextInt(5) + 2;
    try {
      TimeUnit.SECONDS.sleep(r);
    } catch (Exception e) {}
    System.out.printf("[%d]%s\t%s%n", r, new Date(), Thread.currentThread().getName());
  });
});
forkJoinPool.shutdown();
forkJoinPool.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS);

ThreadPoolExecutorの場合

[3]Wed Oct 18 02:04:18 JST 2017  ForkJoinPool.commonPool-worker-3
[4]Wed Oct 18 02:04:19 JST 2017  ForkJoinPool.commonPool-worker-2
[5]Wed Oct 18 02:04:20 JST 2017  pool-1-thread-1
[5]Wed Oct 18 02:04:20 JST 2017  ForkJoinPool.commonPool-worker-1
[2]Wed Oct 18 02:04:20 JST 2017  ForkJoinPool.commonPool-worker-3
[3]Wed Oct 18 02:04:22 JST 2017  ForkJoinPool.commonPool-worker-2
[4]Wed Oct 18 02:04:24 JST 2017  pool-1-thread-1
[4]Wed Oct 18 02:04:24 JST 2017  ForkJoinPool.commonPool-worker-1
[3]Wed Oct 18 02:04:25 JST 2017  ForkJoinPool.commonPool-worker-2

ForkJoinPoolの場合

[2]Wed Oct 18 02:03:06 JST 2017  ForkJoinPool-1-worker-0
[2]Wed Oct 18 02:03:06 JST 2017  ForkJoinPool-1-worker-1
[3]Wed Oct 18 02:03:09 JST 2017  ForkJoinPool-1-worker-1
[4]Wed Oct 18 02:03:10 JST 2017  ForkJoinPool-1-worker-0
[2]Wed Oct 18 02:03:11 JST 2017  ForkJoinPool-1-worker-1
[2]Wed Oct 18 02:03:12 JST 2017  ForkJoinPool-1-worker-0
[3]Wed Oct 18 02:03:15 JST 2017  ForkJoinPool-1-worker-0
[4]Wed Oct 18 02:03:15 JST 2017  ForkJoinPool-1-worker-1
[2]Wed Oct 18 02:03:17 JST 2017  ForkJoinPool-1-worker-1
[3]Wed Oct 18 02:03:18 JST 2017  ForkJoinPool-1-worker-0
[4]Wed Oct 18 02:03:22 JST 2017  ForkJoinPool-1-worker-0

WHY..?

なぜだろうと思いソースを追いかけると、ForkJoinTaskで次のコードが。

private int doInvoke() {
    int s; Thread t; ForkJoinWorkerThread wt;
    return (s = doExec()) < 0 ? s :
        ((t = Thread.currentThread()) instanceof ForkJoinWorkerThread) ?
        (wt = (ForkJoinWorkerThread)t).pool.
        awaitJoin(wt.workQueue, this, 0L) :
        externalAwaitDone();
}

parallel()で使われるForkJoinPool.commonPoolもクラスはForkJoinWorkerThreadなので、ちょっと特別扱いされてるのかー。
ていうか、こんなん分かるわけないよ。

でも、これって実行した後の話だよね。。

“commonで実行しようと思ったけど、callerがforkjoinだからそっちで実行しよう” みたいな処理じゃないと辻褄が合わない気がする。他の場所にあるのかな？

ForkJoinTaskのこれか。

public final ForkJoinTask<V> fork() {
    Thread t;
    if ((t = Thread.currentThread()) instanceof ForkJoinWorkerThread)
        ((ForkJoinWorkerThread)t).workQueue.push(this);
    else
        ForkJoinPool.common.externalPush(this);
    return this;
}

• ForkJoinTaskは木構造を作っている(これを実行したらこれを実行するみたいなグラフ)
• ForkJoinスレッドの中でForkJoin(parallel()も同様)を実行すると、この構造に連結されていく
• ForkJoinPool.submit(stream.parallel().forEach) はこの構造を一気に構築する。
• この構造上、途中に遅いヤツが居ると後続の処理は全て引きずられる
  • 待機列を一気に構築して、それぞれ処理する。並び替えは不可。というイメージ。
  • 時間が経過すると、一番遅いヤツに引きずられて空きWorkerだらけになる。
  • (スーパーのレジのイメージで、かつ100人の客が居たらいっきに100人分の列と順番を決めてしまう)
• これに対してExecutorServiceは1つの行列(Queue)にタスクを積んで、空きWorkerができ次第順処理される
  • (コンビニのレジの列のイメージ)

この記事 の現象はまさにそれかなと思いました。

参考

• http://d.hatena.ne.jp/yohhoy/20140613/p1
• https://qiita.com/ApplePedlar/items/25d13af73a544bc7940c
• http://www.baeldung.com/java-8-parallel-streams-custom-threadpool

分からない事を分からないと意思表示するのは大事な事。
分からない事を分からないまま進めたり、想像で補完して変な事になったり。自分には分からない事を質問された時に、適当に答えて間違った情報を流すのでは無く、近くに居る専門家に助けを求めたりプロキシしたりしないといけない。

分からない事は恥では無く、分からないままにしておく事の方が恥だと思う。

新人じゃないんだし30過ぎた人にわざわざ指摘するのもなぁという思いと、これ系で頭を悩ませる人はだいたい改善しない傾向が強いので、フォローするのも既に面倒な状態になっている事が多い。

社内でstrengths finderが流行っているのでやってみました。
簡単に言うと、2択の質問に1問20秒以内に約200門ほどの回答をWebからします。1時間くらいかかります。そうすると、34の指標から自分がどういう思考性を持っているのかを教えてくれるのです。

こちらの書籍を購入すると、アクセスコードが付いてきて上位5個まで見ることができます。34個全部を見るには1万円ほど払う必要があるっぽいです。

だいたい合っている気がする..

たむたむの上位5件

1. 個別化
2. 活発性
3. 学習欲
4. 慎重さ
5. 着想

1. 個別化

「個別化」という資質により、あなたはひとりひとりが持つユニークな個性に興味を惹かれます。あなたはひとりひとりの特徴や個性を覆い隠したくないので、人を一般化したり、あるいは類型化することに我慢できません。むしろ、個人個人の違いに注目します。あなたは本能的にそれぞれの人の性格、動機、考え方、関係の築き方を観察しています。あなたはそれぞれの人生における、その人にしかない物語を理解します。この資質によって、あなたは、友達にぴったりの誕生日プレゼントを選んだり、ある人は人前で誉められることを好み、別の人はそれを嫌うことを分かったり、一から十まで説明して欲しい人と、一を示せば十を知る人とに合わせて、教え方を調整できたりするのです。あなたはほかの人の強みをとても鋭く観察する人なので、ひとりひとりの最もよいところを引き出すことができます。この個別化という資質は、あなたが生産性の高いチームを作ることにも役立ちます。完璧なチームを作るに当たり、チームの「組織構造」や「作業手順」に着目する人もいますが、あなたは優秀なチーム作りの秘訣は、各自が得意なことを充分に発揮できるような、強みに基づく配役である、ということを本能的に知っています。

あなたが卓越している点は?

強みによって、あなたは、人を団結させます。あなたは相手の状況を理解し始めると、それぞれの人との絆を築きます。あなたは自然と相手の状況に一体感を持ちます。あなたは人が共通点を発見できるように手助けする才能を持ちます。このためその人たちが気楽にやり取りして協力し合えるようになることがよくあります。あなたは本能的に、一人ひとりの違いを察知する才能があるかもしれません。あなたは、多様性は悪いことではなく、むしろ良いことであると考えているかもしれません。あなたは、多様な背景を持つ人々がチームの成功のために協力する方法を見つけるためにサポートできるかもしれません。生まれながらにして、あなたは、ときどき、あなたに助けを求める友人にアドバイスをすることがあります。あなたは、自分の意見、提案、アドバイスについては、人から言ってほしいと依頼されない限り、自分の中にとどめておくでしょう。多くの場合、あなたは、ときどき、自分の実践的、率直または現実的な考え方が特定の人から評価されていることに気付くことがあります。あなたがすべての人を平等、同等に扱っていることの価値を分かってくれる人の支援に喜びを感じるでしょう。持っている才能によって、あなたは、先を見据える人達が経験する試練、苦境、孤独を敏感に感じ取ります。人々が彼らのアイデアを冷淡かつ無神経に見捨てたとしても、未来志向の人々はこれからの数か月、数年、または数十年の間に達成可能なことに関する彼らのビジョンをあなたが評価することを感じ取ります。

2. 活発性

「いつ始めようか？」これはあなたの人生で繰り返される質問です。あなたは動き出したくてうずうずしています。分析が有用であるとか、ディベートや討論が貴重な洞察を生み出す場合があることもあなたは認めるかもしれませんが、心の奥深くでは、行動だけが有意義であると知っています。行動だけが何かを起こすことができるのです。行動だけが功績につながります。決断が下されると、あなたは行動を起こさずにはいられません。ほかの人は「まだ知らないことがあるのに」と戸惑うかも知れませんが、あなたのペースを遅くすることはなさそうです。街の中を横断する決定を下した場合、最も速く移動する方法は信号から信号へと渡り歩くことです。すべての信号が青になるまでだらだらと待っているわけではありません。そのうえあなたの考え方では、行動と思考は互いに相容れないものではありません。事実、「活発性」の資質によって、あなたは、行動は最良の学習手段であると考えています。あなたは決断し、行動し、結果をみて、そして学びます。この学習方法によって、あなたは次の行動、そしてさらに次の行動へと導かれるのです。もし行動しなかったら、どうやって成長できるのでしょう？あなたは、行動がなければ成長できないと考えています。あなたは、危険を冒してでも行動し続けなければなりません。次の行動を起こさなければなりません。思考を常にいきいきと豊かにしておく方法が、他にあるでしょうか。発言したことや考えたことによってではなく、実行したことによって判断されるということを、あなたは知っています。これが重要なのです。あなたはこれを恐れることはありません。あなたにとって、これが喜びなのです。

あなたが卓越している点は?

おそらくあなたは、ある種のスタートアッププロジェクト、プロセス、手続き、構想などを引き受けるために、名乗りを上げる場合があります。それは、あなたが自分の才能、技術、知識が目前の作業に釣り合うことがわかっているときでしょう。ときどき、具体的な試みを選択して、陣頭指揮を取ろうとします。しかし、成功に必要な専門知識が欠けている場合は、誰かにリーダーシップの役割を引き受けさせることもあります。強みによって、あなたは、チームの中で、ときどきプロジェクトの立ち上げ、会議の開始、プロセスの開始に携わるかもしれません。計画の立案が長引くと、うんざりしてくるかもしれません。そういうとき、忙しく立ち働きたい、何か行動を起こしたいと思うでしょう。持っている才能によって、あなたは、何かを任されたがっています。あなたは決心した途端に始めたくなります。進捗を邪魔する人にはおそらくイライラさせられることでしょう。生まれながらにして、あなたは、ときどき、仕事や学習を開始するために必要な刺激、原動力や報酬を人に与えることがあります。あなたは、特定の考え、プロジェクト、変更、規制、提案などに対して抵抗がある人がそれらを克服できるように手助けするかもしれません。あなたは本能的に、節度を持って行動したり、言葉を選んで話したりすることがあります。あなたは、状況や目の前の人に影響を受け、発言したり行動したりすることもあります。しかしあなたは、個人的な事柄は自分の胸にしまっておくことを選ぶようです。自分の経験について話すことよりも、ある種のプロジェクトを立ち上げることを好むのかもしれません。

3. 学習欲

あなたは学ぶことが大好きです。あなたが最も関心を持つテーマは、あなたの他の資質や経験によって決まりますが、それが何であれ、あなたはいつも学ぶ「プロセス」に心を惹かれます。内容や結果よりもプロセスこそが、あなたにとっては刺激的なのです。あなたは何も知らない状態から能力を備えた状態に、着実で計画的なプロセスを経て移行することで活気づけられます。最初にいくつかの事実に接することでぞくぞくし、早い段階で学んだことを復誦し練習する努力をし、スキルを習得するにつれ自信が強まる――これがあなたの心を惹きつける学習プロセスです。あなたの意欲の高まりは、あなたに社会人学習――外国語、ヨガ、大学院など――への参加を促すようになります。それは、短期プロジェクトへの取組みを依頼されて、短期間で沢山の新しいことを学ぶことが求められ、そしてすぐにまた次の新しいプロジェクトへに取組んでいく必要のあるような、活気に溢れた職場環境の中で力を発揮します。この「学習欲」という資質は、必ずしもあなたがその分野の専門家になろうとしているとか、専門的あるいは学術的な資格に伴う尊敬の念を求めていることを意味するわけではありません。学習の成果は、「学習のプロセス」ほど重要ではないのです。

あなたが卓越している点は?

あなたは本能的に、情報の輪に加わっていたいタイプです。起こっていることすべてを把握したいと考えています。自分に直接関係がなくても、常に最新の変化を知っておきたいのです。当然、重要なプロジェクトや納期、発見、問題、成功などに関するニュースを誰かがうっかり、または故意に伝えなかったとき、あなたは非常に困惑し、不満を抱きます。生まれながらにして、あなたは、何時間も続けて集中することができます。特に新しい情報を調べることで、理解を深めたり、独創的な発想を生み出したりする場合はなおさらです。このような熱意によって、機会あるごとに、さらに知識やスキルを習得しようと心に決めるようです。おそらくあなたは、精神的および身体的なエネルギーを要求された仕事に向ける一方で、任意的な仕事にはさほど注目しません。そのような状況下では、仕事や研究を何時間も続けられることが有利に働く場合があります。生物学的な性質によって、最も警戒するとき、最も効率的または生産的になる時が決まります。多くの場合、あなたは、他のことに気を取られずに課題に集中できます。ときには、特定のテーマについて知っておく必要のあるすべてのことを理解するまで、読書、調査、実験、執筆などを続けることがあります。特定の概念を習得したり、重要な情報を記憶することに熱心に取り組んだり、特定のコースの必修科目を終えたりするまで休まないことがあります。持っている才能によって、あなたは、手間隙かけて、物事が起こった経緯と理由を突き止めます。そして、わかったことをパートナー、チームメンバー、友達に話します。あなたは通常、合理的に説明します。重要な事実のみを取り上げます。ほとんどの人はあなたの言うことを簡単に理解できます。あなたが事細かい説明ではなく、要点を理解できるよう話してくれ、聞いている側はたいへん有り難く感じていることでしょう。

4. 慎重さ

あなたは用心深く、決して油断しません。
あなたは自分のことをあまり話しません。あなたは世の中が予測できない場所であることを知っています。すべてが秩序正しいように見えますが、表面下には数多くの危険が待ちかまえていることを感じ取っています。あなたはこれらの危険を否定するよりは、一つひとつを表面に引き出します。そうして、危険はひとつずつ特定され、評価され、最終的に減っていきます。いうなれば、あなたは毎日の生活を注意深く送る、かなりまじめな人です。

例えば、何かが上手くいかない場合に備えて、あらかじめ計画を立てることを好みます。あなたは友人を慎重に選び、会話が個人的な話題になると、自分のことについては話しをせず、自分自身で考えることを好みます。誤解されないように、過度に誉めたり認めたりしないように気をつけます。人になかなか打ち解けないという理由で、あなたを嫌う人がいても気にしません。あなたにとって、人生は人気コンテストではないのです。人生は地雷原を歩くようなものです。そうすることを望むならば、他の人は用心せずにこの地雷原を駆け抜けるかもしれません。しかし、あなたは違う方法をとります。あなたは危険を明確にし、その危険が及ぼす影響を推し量り、それから慎重に一歩ずつ踏み出します。あなたは細心の注意を払って進みます。

あなたが卓越している点は?

持っている才能によって、あなたは、自分の人生に対するある種の事実を胸にしまっておくことを選んでいます。仕事、プロジェクト、または肩書きのせいで自分が公的な立場に置かれるのであれば、それらを避ける場合があります。多くの場合、あなたは、友人を慎重に選びます。あなたは、選び抜いた人と近くて親密な関係を育てることで満足感を得ます。友人と呼べる人の数が多いことより、質の良い関係を持つことの方があなたにとってはずっと重要です。生まれながらにして、あなたは、自分自身や自分の考え、気持ちについて多くを語らないようにしています。率直になり過ぎるリスクの可能性をおそらく重視しているでしょう。特別な称賛に値することが十分に証明されるまで、人々やグループの才能、貢献、成果を認めないことがあります。あなたは本能的に、好ましい結果を助長することを重視します。あなたは他の人の良い点を見つけて強調します。あなたは人に得意なことについての具体的な特定の詳細事項を伝えます。そして才能を活かせるように手助けします。これがその人の継続的な成功につながると、あなたは主張します。おそらくあなたは、自分が維持する人間関係や「友人」と呼ぶ人々の選択にはこだわりを持っています。多くの人から、特定の時点において彼らが何を考え、何を感じているのかを鋭く感じ取る人だと思われています。

5. 着想

あなたは着想に魅力を感じます。では、着想とは何でしょうか？着想とは、ほとんどの出来事を最もうまく説明できる考え方です。あなたは複雑に見える表面の下に、なぜ物事はそうなっているかを説明する、的確で簡潔な考え方を発見すると嬉しくなります。着想とは結びつきです。あなたのような考え方を持つ人は、いつも結びつきを探しています。見た目には共通点のない現象が、何となく繋がりがありそうだと、あなたは好奇心をかき立てられるのです。着想とは、皆がなかなか解決できずにいる日常的な問題に対して、新しい見方をすることです。あなたは誰でも知っている世の中の事柄を取り上げ、それをひっくり返すことに非常に喜びを感じます。それによって人々は、その事柄を、変わっているけれど意外な角度から眺めることができます。あなたはこのような着想すべてが大好きです。なぜなら、それらは深い意味があるからです。なぜなら、それらは目新しいからです。それらは明瞭であり、逆説的であり、奇抜だからです。これらすべての理由で、あなたは新しい着想が生まれるたびに、エネルギーが電流のように走ります。他の人たちはあなたのことを、創造的とか独創的とか、あるいは概念的とか、知的とさえ名付けるかもしれません。おそらく、どれもあてはまるかもしれません。どれもあてはまらないかもしれません。確実なのは、着想はあなたにとってスリルがあるということです。そしてほとんど毎日そうであれば、あなたは幸せなのです。

あなたが卓越している点は?

あなたは本能的に、メンバーの中で、独創的な仕事のやり方を提案する役目を果たすことがあります。他のメンバーより画期的なアイデアを提案することがあります。持っている才能によって、あなたは、人々の言葉に耳を傾け、彼らが自分のことをどう考え、どう話しているかを突き止めます。あなたは、人々があなたをどう見ているかを敏感に察しています。あなたはおそらく、一部の心をつかみ、その他の人を感心させたいのでしょう。おそらくあなたは、ときどき、独創的なアイデアを生み出せる機会を活用することがあります。生まれながらにして、あなたは、特定の業務やプロジェクトに対して新しい革新的なアイデアを生み出すことができるとうれしく思うかもしれません。あなたはおそらく標準の業務手順に従わざるを得ない場合には、熱意を失ったり飽きたりするでしょう。あなたはしばしば、創造性が抑圧されると、仕事や学習コースが自分に合っているのだろうかと疑問に感じます。あなたは、自分の独創的な提案を、批判や不服、つまり権力への服従に対する拒否の表れと捉える人に、不満を抱くことがあるでしょう。強みによって、あなたは、グループのメンバーから独創的な考えを当てにされているでしょう。おそらく、誰かが問題やチャンスを説明するとすぐに、あなたの頭にアイデアが浮かぶでしょう。

RubyのSequelというライブラリのお話。 mysql=5.5.42 sequel=4.25.0

db[:log_delay].where(:send_dg => false).order(:event_at).limit(1000).all

こんな処理を書いていて、なんか遅いなー(state=Sorting resultで詰まっている)と思ったら、以下のSQLに変換されていました。

SELECT * FROM `log_delay` WHERE (`send_dg` IS FALSE) ORDER BY `event_at` LIMIT 1000

IS FALSE..だと!? なお、インデックスは send_dgとenvet_atに付けています。

本来発行したいSQLは以下です。

SELECT * FROM `log_delay` WHERE (`send_dg` = false) ORDER BY `event_at` LIMIT 1000

こう書いたら目的通りのSQLが生成されました。

db[:log_delay].where(:send_dg => Sequel.lit('false')).order(:event_at).limit(1000).all

そして詰まりも無くなりました。