この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

今回は、対人ゲームの最たる例である1vs1の格闘ゲームにおける初心者について考える。 なお、ここでは初心者とは「格闘ゲーム」というジャンルに初めて触れる人を指すことにする。

ユーザーのレベル帯

　先に格闘ゲームにおける各プレイヤーのレベル帯について軽く説明すると以下のようになる。
（※あくまで個人的な見解です）
初心者：右も左も分からず、コンボどころかキャラの操作もおぼつかない状態。
初級者：ある程度コンボはできるが、対戦ではあまり勝てない状態。
中級者：立ち回りや自分が使っていないキャラの特徴も覚え、十分に対戦できる状態。
上級者：状況に応じた最適な選択ができ、中級者に大抵勝てる状態。

格闘ゲームにおける初心者の離脱問題

　「格闘ゲームは人が減った」と言われるようになって久しいが、その理由としてよく挙げられるのが「初心者が定着しない」である。原因としては「ハードルが高い」「難しい」「初心者狩り」「1vs1がつらい」など様々なことが言われている。
　「1vs1がつらい」は個人の好みの問題なのでどうしようもないが、「ハードルが高い」「難しい」「初心者狩り」については対策が進んでいる。

・「ハードルが高い」について
　格闘ゲームといえばゲームセンターでアーケードコントローラーでガチャガチャしてやってる、という認識が強いし、事実現在でもトッププレイヤーは大抵そうである。ゲームセンターは強い人がたくさんいるし、環境も良くなさそうで敬遠、という感じに新規ユーザーの足は遠のいている。
　しかし、昨今は家庭用ゲーム機で同じゲームがプレイでき、アーケードコントローラーではなく通常のパッドのコントローラーを使うこともできる。オンラインなので初心者同士の対戦相手にも困らないというのが実情である。

・「難しい」について
　初心者は先に説明した通り、キャラの操作すらままならない。そもそも技の種類やコマンドすら把握していないことも普通である。最近の格闘ゲームではこの対策として、ゲーム開始時に「経験済みか」の確認が入り、「いいえ」を選ぶとコマンドなどを覚えるモードを推奨され、クリアするまでオンライン対戦が封印されるといった仕組みも見受けられる。そして一通りの練習後、ＣＰＣ対戦で慣れてから晴れてオンライン対戦、というのが正道となる。

・「初心者狩り」について
　自分より弱い相手を狙ってボコボコにして楽しむ悪質なユーザーや行為を「初心者狩り」と呼び、初心者がゲームを離れる要因として挙げられる。しかし、初心者視点では相手が「わざと初心者と対戦している」かは判断できないため、そのつもりがなくても「初狩りされた。つまらない」という気持ちを生んでしまうことがある。
　オンライン対戦ではその性質上、ゲーム開始時点では全ての人の評価が同じため、強者と初心者が対戦することが起こってしまう。対人ゲーム自体が初めてだと、そういうシステムであることすら知らないため、「自分と同レベルの相手と戦えると思ってた」なんて話を聞くこともある。

既存ユーザーにとっての初心者

　初心者が入ってくることはそのコンテンツの維持や成長に必須のため、基本的に肯定的であるのだが、対戦相手にはなりたくないのが正直なところである。初心者狩りが好きな場合を除けば、自分と同格か格上と戦って勝つのが対人の楽しさの醍醐味なので、初心者と戦っても得られるものは無いからだ。
　（ただ、「教える」という機会は勉強と同じで自身の復習にも繋がるので、初心者は臆せず質問するのは歓迎されることも多い）

まとめ

　初心者もそうでない人も、基本的には「自分と同格か格上に挑んで勝って、強くなりたい」というのが対人ゲームにおける共通の思いである。力量に覆しようのない差がある者同士が対戦してしまうと互いに不幸なだけであるので、例えばオンライン対戦の初めに自分の強さを自己申告した後にテスト対戦をして評価をするといったシステムで不幸を減らすことがユーザー数の維持に繋がるのではないだろうか。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

はじめに

　みなさんはマウスとトラックパッド、どちらが好きですか？
私はトラックパッドが使いやすくて大好きです。しかし最近ふと思い返して考えてみたのですが、周りにトラックパッド派がいないです。仕事中に他の人にPCを触らせる時も「マウスない？」と聞かれます。なんでそんなに嫌われているのでしょうか…。
普段MacBookを使用しているので、MacBookを使用する観点からトラックパッドとマウスの操作性についてまとめてみました。
　

メリット

少ない動作で多彩な操作が出来る

　macbookの場合、キーボード直下に存在するトラックパッド。
PC本体の横に置いてあるマウスより手の移動距離が少ないのは明らかですね。
スワイプ一つでも、1本だとカーソル移動、2本だとスクロール、もしくは前のページに戻る、次のページに進む、3本だとフルスクリーンスワイプを行うことができます。ズームイン、アウトもスマートフォンと同じような操作で行うことができます。
　

場所を選ばず、持ち運びが楽

　例えば仕事で自席から離れてPCをどこかへ持っていかないといけなくなった場合。
マウスの場合荷物が一つ増えるし、折角持って行ったのにその行き先にテーブルがなかったら。
結局持って来たのにマウスが使えない、なんだか残念な気持ちになりますね。
それに普段マウスを使っている人からすると、慣れないトラックパッドは使いづらいです。
　

とっても静か

　マウスの場合必ずクリック音と机との摩擦音が伴います。
トラックパッドの場合だと、まず摩擦音が全くないです。クリック音も多少なりしますが、サイレントマウスと比べても静かです。それにサイレントマウスの場合は、経年劣化でだんだん音が鳴るようになってくることも多いですよね。
この操作音の差、私がメインでトラックパッドを使うようになった一番の理由です。
　

デメリット

　一方的にマウスを否定する記事になってしまったので、逆にデメリットも挙げておきます。

ドラッグ操作が煩わしい

　マウスの場合、机の隅に来てもドラッグした状態のままテーブルから一旦離し、またテーブルに置き直してスライドさせればどこまでもドラッグすることができます。
ですが、トラックパッドでドラッグを1本指でしようとするとトラックパッドの範囲内でしか行うことができません。
1本ドラッグした状態のまま違う指でスワイプすると、広い範囲でドラッグを行うこともできますが、途中で指を離してしまったりすると1から選択し直しになるため、煩わしいと感じる人もいるようです。
　

右クリック操作しにくい

　マウスと違い、右クリックを1本指で行うことができません。controlを押しながらクリックするか、設定にもよりますが2本指でクリックする必要が出て来ます。
私の場合は「2本指クリックで右クリック」操作はどうも相性が悪く、誤操作ばかり起こしてイライラしてしまうので、無効にしてcontrol+クリックだけを使用しています。
　

最後に

　ここまでトラックパッドを全面に推していきましたが、私は数年前までマウス派でした。
学生時代にマウスを使ってはいけない制限があるなか仕事をしなければならず、文句を言いつつ調べて使ってみたら想像を越える便利さ。驚きました。
マウス派の方でも少し興味を持たれた方がいたら、是非調べてカスタマイズしながら使ってみてください。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

ついついやってしまううっかりミス。 悪いことって不思議と繋がるものでミスした次の瞬間、またミスが… 今回は少しでもミスを減らすためのコツをご紹介します。

①もう一度確認をする！

出来たらおしまい！…ではなく今一度確認をしましょう。
テストでも見直しが大切と小学校で教わったように確認は重要です。

自分でやってももちろん良いですが、他の人に頼んでやってもらえると
視野が広がるのでミスの発見もしやすいと思います。

②余裕を持つ！

焦りはミスを生みやすいです。
どうしても注意力が下がってしまいます。

余裕があれば確認の時間も十分取れますね。

③十分な睡眠を取る！

疲れて眠いときに確認なんて出来ませんし、やってもあまり意味はないでしょう。
ましてや余裕なんてあるわけもなく…。

睡眠不足による疲労、ストレスはミスの大きな原因です。
しっかりと睡眠を取りましょう。

④集中しやすい環境作りをする！

人によって静かな環境が良い人もいれば
少し雑音があった方が集中できる人もいるでしょう。
自分にあった環境を見つけましょう。

⑤ミスしたら対策する！

人間はどうしてもミスをします。仕方ありません。
ではどうするのか？

同じミスを繰り返さないようにすることです。
ミスの原因をしっかりと把握して対策を立てましょう。
日頃から常に意識していくことによって未来のミス防止にも繋がります。

まとめ

①もう一度確認をする！
②余裕を持つ！
③十分な睡眠をとる！
④集中しやすい環境作りをする！
⑤ミスしたら対策する！

とても当たり前に感じることばかりだと思いますが
それでもミスは起きています。
馬鹿にせず少し意識してみるとミスは減るかもしれません。

※本記事の内容は個人の見解によるものになります。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

1つの大きなタスクが終わったり、イベントなどのまとめ役等をした後に振り返りを行うことで自分をより成長させることができるそうです。調べてみると振り返りの方法にも様々な型があったため実際に振り返りながらまとめてみたいと思います。

はじめに

チームでの大きめな開発が一区切り付くごとに振り返りを行った方が良いという話が上がり、KPT法という振り返り方法があることを知りました。
なので今回はKPT法について調べたことをまとめて書こう…！と思ったのですが、既にこのDoruby内で記事になっていたので、今回はKPT法以外のYWT、PDCAという振り返り法を実際に振り返ってみながらまとめてみようと思います。(KPT法についてはこちらの記事をご覧ください <生産的な振り返り方法「KPT」について>)

YWT、PDCAとは

YWTとはY(やったこと)、W(わかったこと)、T(つぎにやること)の頭文字から取っていて、言葉からわかるように日本発祥の振り返り手法です。
手順は以下の3つです。
①まずはY(やったこと)をできるだけ書き出します。
②Yの内容からW(わかったこと)を書いていきます。
　Wに繋がらないYがあっても大丈夫なので分かったことがあったものだけ書いていきます。
③そしてWで分かったことから、次どうすれば良いかをT(つぎにやること)に書いて振り返ります。

PDCAはPlan(計画)⇒Do(実行)⇒Check(評価)⇒Action(改善)の頭文字で、この4つを繰り返し行うことで自分の行動を見つめ直し、次の新しい行動につなげ、生産性や品質の向上などが見込める振り返り手法です。

YWTは実際に経験してからの振り返り、PDCAは計画をしっかり行った上でどうだったかの振り返る手法となります。

実際に振り返ってみよう

YWT、PDCAについて分かったところで実際に振り返ってみたいと思います。
複数部署合同の懇親会を、新卒が企画して社内会議室で行ったので、その振り返りをYWTで行ってみようと思います。

・YWT


記事に書ける範囲をYWTで書いてみました。
開催から日がちょっと空いてしまったので思い出しながらの記入でしたが「どこで苦労した」とか「こういう風にしとけばよかった」などの気づいた部分を残しても置けるので、次回やる時に見返すだけでもだいぶ効果がありそうだなと思いました。
今回は終了後の振り返りだったためYWTを使いましたが、次回からはT(つぎにやること)を意識して、PDCAのP(計画)から行うのもアリだと思います。

おわりに

自分はあまり振り返って考えるという事をしてこなかったので今回いろいろと調べてとても勉強になりました。
今回は社内のイベントについて振り返りを行ってみましたが、普段業務で行っているタスクが片付いた時や、仕事に限らず何かを行った後にちょっとだけ時間を割いて振り返ってみることで次回以降が楽になるかもしれません。
振り返りは継続して行うことが大事なので、無理せず自分の出来る範囲で行ってみてはいかがでしょうか？

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

はじめに

社会人になって思う事は仕事に集中しすぎていつの間にか時間がたっていると思う事です。
仕事が早く進むのはいいことですし休んでる暇なんてないと思いがちですが、
やはり集中力にも限界があります。
集中力が続かなければ仕事にも影響が出たり逆に効率が悪くなります。
今回は短い時間でも息抜きになる方法をいくつか調べてみました。

ストレッチ

長時間同じ態勢でいると血行の流れが悪くなり脳に十分な血液と酸素が行き届かなくなるのだそうです。ボーっとしたり考えがまとまらない時などは、伸びをしたり凝りをほぐすなどしてみるのがいいかもしれません。

水分を取る

脳は8割が水分でできており、水分が不足すると集中力・記憶力が低下してしまいます。冷たいものより常温か白湯のほうが体が急激に冷えず体内に摂取しやすくなります。
集中力したいことの前に水を取り、いっきに飲むのではなくこまめに摂取するのが大切なようです。

ブドウ糖の摂取

血液中のブドウ糖を増やし脳にエネルギーを与えることができます。
糖分の取り過ぎは血糖値が急激に上がりそのまま急低下して集中力が下がってしまうので、量はほどほどに取るのがいいそうです。
甘いものが苦手ならガムでもよく、咀嚼行為そのものが能をリラックスにする効果があり、筋肉を使うため眠気覚ましにもなります。

最後に

休憩にスマホやネットサーフィンをするのは気分転換にはなるかもしれませんが
脳が休めていないので逆効果になってしまいます。
集中力を調整できれば効率良く作業が進められそうです。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

番外編「VRやARってなんだろう？」について話していきたいと思います。

みなさんこんにちは、Lionです！
今日は番外編と題して「VRやARってなんだろう？」話していきたいと思います。
最近、よく耳にするVRやARですが、みなさん一体どういうものかは実は知らなかったりしませんか？
何となく知っていても実際はどんなものでどんな違いがあるか…？
そういう方へ向けて、簡単に説明していきたいと思います。

VRとはなんだ？

VRとはバーチャルリアリティの略称です。いわゆる仮想現実というものになります。
VRは、仮想世界を含めたあらゆる体験を、時間や空間を超えて、本当の現実世界のように表現するための技術や手法と思っていただければいいかと思います。

もう少し詳しく説明すると、コンピューターや電子技術を用いて、人間の視覚、聴覚、触覚、嗅覚、味覚といった五感を刺激して、「現実世界に今いるのに目の前は2次元の中にいる！？」と思わせることができます。

この技術が近年急成長しており、現実世界でいても魔法が使えたり剣を振ってモンスターを倒したりする体験がようにできるゲームが増えてきました。また、医療現場やスポーツなどのシミュレーションに使われたりなどでも浸透しつつあります。

ARとはなんだ？

ARとはオークメンティッドリアリティの略称です。いわゆる拡張現実というものになります。
ARは現実世界で人が感知する情報に、「何か別の情報」を加えて表現することの技術や手法と思っていただければいいかと思います。
もう少し詳しく説明すると、視覚だけでは感知できない情報を付加して表示するというものがオーソドックスです。

例えばですが、スマホやタブレットのカメラ映像に表示される現実世界の映像に対して、位置情報などのデータや、実際にはその場にないはずの映像やCGを重畳させて表示するといったものになります。
例えば、家の中で動画撮影をしているとして、ある位置にカメラを向けてみると「金髪ツインテールの美女が出現する！？」といったものですね。現実にはいませんが、カメラを通してみるとあたかもそこにいるかのように見えてしまいます。

VRとARの違いは？

違いとしては

VR
「いろいろなようで作られた現実のような世界に、ユーザ自身が飛び込むんで自ら体験する」
※使用する機械はHMD（ヘッドマウントディスプレイ）など

AR
「今自分がいる現実世界の情報に、何か別の情報を追加して表現または利用する」
※使用する機械はスマホのカメラなど

となります。まぁーもっと大雑把に言えば「二次元の中に自分から行くぜ！」か「二次元にあるものを現実世界に召喚するぜ！」といった形でしょうか（笑）

ここまで話してみて

ちなみに私は、VRの方が大好きです（唐突）
趣味でHMDとUnityを用いて仮想空間を開発したりしています（もちろん可愛い女の子もいますよ？ええそりゃもちろん）

近い未来、二次元の世界にもっとダイブできるようになったり、または、私たちの現実世界に二次元のキャラなどが現れて一緒に生活したりすることもあるかもしれませんね！

今回の話はこれでおしまい！VRとARの違いが少しでも分かっていただければ嬉しいです！では、バイチャ(‘ω’)ノ

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

第9回「就活の時にやっちゃいけない3つの事柄」について話していきたいと思います。

みなさん！こんにちは！Lionです。
前回の記事いかがだったでしょうか？
「必勝？！筆者独自の就活術」というのが少しでも役に立ちましたら、嬉しいです！
さて、本日は逆に「就活の時にやっちゃいけない3つの事柄」について話させていただきます。
※あくまで筆者の考え方や実体験なので、参考程度でお願いします

大学の単位は早めにとっておくこと！

私自身の経験談で語らせていただきます。
自分は理系の大学だったのですが、割と単位がカツカツでした。
その上、卒業研究という大きな取り組みを一年間行わなければいけないため、就活に時間をなかなか割けないようになってしまいました。
そうなってしまうと、他の人より就職活動の遅れが出てしまい焦ってしまいます。

ではそうならないようにするには、

①大学4年生になったら4年生で取らなければいけない必修科目以外の単位は全部終わらせておくこと
②卒業研究はこまめに取り組み、大学の教授と就活の連携をとること

この2つを取り組んでいれば、スムーズな就職活動が行えるようになります。

インターンシップには積極的に取り組め！

就職活動が始まると色々な会社でインターンシップが行われるようになります。
積極的にインターンシップは受けましょう。
※ただし、自分が就職したい職業のインターンシップをきちんと選びましょうね。
私自身は、卒研や単位取得などで時間がなく、インターンシップを受けなかったのを未だに悔やんでいます。

そんなインターンシップの良いところですが

①その業種の取り組んでいる仕事を知ることができる
②インターンシップ中に採用が急にされることもある
③インターンシップの数だけ自分の就活実績になる

と良いことだらけです。

ただ、複数のインターンシップを同時に受けるのはなるべくやめましょう。
スケジュール管理や体調管理が大変なので…。
なるべく1本に絞って取り組むのがベストでしょう。

夜遅くに履歴書は書かないように！

学校の授業や卒研、就職活動で外に出向いたりすると、なかなか時間が取れなくなります。
そうなると、会社指定の課題や履歴書を作成するのが夜になっちゃうことが多々ありました。
例えば忙しかった夜に書くと、集中力が低下して誤字を書いてしまっているのに気づかずそのまま提出してしまったり…などと恥ずかしいことも起こります。

そうならないために

①深夜には履歴書や課題には取り組まない
②前もってスケジュール管理を行って、余裕をもって提出1週間前の土日に書く

こうするとより良いものを書くことができます。
締切り一日前に慌てて書くようなことはやめましょうね。

ここまで話してみて

いかがだったでしょうか？
私も上記に書いたことをやってしまったことがあり、恥ずかしい思いや損だったことなど色々ありました。
特に、インターンシップに関しては未だに心残りですね。
皆さんは、そうならないように余裕をもって就活に取り組んでくださいね(∩´∀｀)∩

さて、次回は「第10回　最近はやりのオープンワールドの魅力とは！？」を話して行きたいと思います。
では、就活生の諸君！未だに大流行しているインフルエンザにはならないようにきちんとした生活をおくって就活頑張ってください(/・ω・)/

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

サーバごとの設定値って大抵同じところに入っていますよね…。ならそれを参照して使えばいいのでは。そんな考えから生まれた記事です。

はじめに

シェルスクリプトを書いているうちに組み合わせると良さそうだなと思ったコマンドがあったので少し紹介を。
本記事ではgrep、awkを取り上げています。

使用例

ファイルの中身(setting.propertiesとします)
something.filepath=something.log
something.filename=wrongfile.log

$ grep 'something.filepath' ./setting.properties | awk -F'=' '{print $2}'

結果
something.log

設定ファイルlogファイル名を入れた際、どの変数に入れたかわかっていれば検索できます。
もちろんlogファイル名がわかっている場合でも同じ結果が表示されますが、ファイル名で検索する場合は「どこで使われているか」が目的になるので awk を利用することはありません。

これをシェルスクリプトで用いるのであれば、例えば設定するファイルが存在するか判定して条件分岐を行う用途があります。
もし存在しなければ処理を行わない、サーバ管理者に通知する…などでしょうか。
ファイル名に限らず、特定の値を抽出するのにも利用できます。

例1

xml内(about.xmlとします)
<title>DoRuby</title>
<page>30</page>
<pageTitle>What is DoRuby?</pageTitle>

$ grep '<page>' ./about.xml | awk -F'>' '{print $2}' | awk -F'<' '{print $1}'

結果
30

例2

ファイルの中身(setting.propertiesとします)
[色々な設定]
app_env=test
[色々な設定]

スクリプト
#!/bin/bash
set -eu
# ^が使えるので利用します
app_env=$(grep '^app_env' ./setting.properties | awk -F'=' '{print $2}')
if [ "${app_env}" = "test" ]; then
  # テスト環境用の処理を書く
elif [ "${app_env}" = "production" ]; then
  # 本番環境用の処理を書く
else
  echo "Missing app_env value."
  exit
fi

echo "Script completed."

set -e を使っている間は grep の結果が0件にならないようにしてください。ただ検索系のコマンドである以上0件もありうるため、その場合は以下のようにして回避します。

・grepのある行で処理する場合
grep '検索文字' || :

・setを使う場合
set +e # エラー発生時、強制終了しないように変更
grep '検索文字'
set -e # エラー発生時、強制終了するように変更

・この記載は戻り値が最後の処理に依存します(今回の例2はok)。'>'といったファイル出力では回避できないので注意
grep '検索文字' | 何かの処理

エラーとみなされる原因として、 grep の取得件数が0件の時、各処理で確認できる戻り値 $? が正常終了である0ではなく1になるためです。そのためエラーだと誤認して処理が途中で止まってしまいます。

おわりに

単純に1コマンドを扱うのではなく、複数のコマンドをつなげる機会が増えてきたのでちょっとした紹介をしました。例は単純なものですので実際に運用する際は、複数参照したり検索ワードを変えたりとなりますが、きっかけになれば幸いです。
操作できることが増えると楽しくなりますね…一方でミスした時のリスクが怖いので、動作するかの確認は怠らないよう心がけています。

参考：
要素検索してパラメータを取得するsed

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

テストコードを書くのは辛い。

　みなさん、テストコードは好きですか？　私は嫌いです。ええ、とても。
　でも、書いた方が良い、よりもうほぼほぼ書かなくてはいけないものなので、書きます。
　書いた方が結果的に楽なので、書きます。
　書くのは辛いけど、書きます。
　辛いのは書く時だけで、後々とても楽になるので書きます。
　それでも辛いけど書きます。
　楽をする為に書きます。
　書きます。

なぜ、テストコードを書くのか

　開発作業では、全ての作業が良いタイミングで進んでいくという事はまずありません。
　例えばサーバー、クライアント両方でAという機能を開発していく時、タスク量としてはサーバー側の方が軽く、実装が完了して実際に動かしてみようとしてもクライアントのAが完成していないから動かせない、という事は多々あります。
　コンソール上からAPIやメソッドを叩いて試す、とか、そんな事もやろうと思えば出来ますが、書いたものはコンソールから出てしまえば全部消えてしまいますし、またAPIからやろうとするとリクエストヘッダが必須だったり、引数が複雑だったりすると色々と面倒です。
　しかし、テストコードを書いておけば、最終的にコマンドを一つ叩くだけできちんと動作するのかが分かり、仕様変更が入った時などもその動作が保証されているのか、実機確認などを挟まずとも簡単に分かります。

↓大体実例。

テストコードを書かない場合(サーバー側)

1. サーバー・クライアント新規実装決定！
2. サーバー実装完了！　でも、クライアントがまだ完了してないから待つしかないよ……。まあ、コンソール上で試したら動くみたいだし問題無いかな。
3. クライアント実装完了！　実機確認！　何？　動かない？　ここが悪いのか。直してコンソールで確認して、ああ面倒臭いな、ユーザー作って条件満たさせて、その状態でここのコード叩いて、あー動かない、ミスった、再度直してまたコンソール叩いて、また違うところでエラー？　はぁ……。
4. 動くようになった！　デプロイ！　もう一度実機確認！　何？　また動かない？　ここが悪いの？　あ、仕様ミスってる！　直してコンソールで確認して、ああ面倒臭いな、ユーザー作って条件満たさせて、その状態でここのコード叩いて、あー動かない、今度はtypoだ、再度直してまたコンソール叩いて、また違うところでエラー？　ここもtypoじゃねえか！　はぁ…………。
5. 動くようになった！　デプロイ！　もう一度実機確認！　何？　動かない？　もう勘弁して！　僕が悪いんだけど！　どこが悪いの！　悪いコード！　書いたの僕だけど！　コンソールで確認して、もう慣れたよこの手順、ユーザー作って条件満たさせて、その状態でここのコード叩いて、あれ動く！　今度はどこミスったの僕！　僕は悪い子！
6. 動くようになった！　デプロイ！　もう一度実機確認！　何？　動かない？　ｳｯ　あ、試してる時に書いたコード消し忘れてる……。
7. できた……。疲れた……。

〜〜〜〜時が過ぎた〜〜〜〜

「その機能仕様変更ね」
「分かりました(ほげぇぇぇぇぇぇぇぇぇぇぇ)」
2に戻る。

テストコードを書いた場合(サーバー側)

1. サーバー・クライアント新規実装決定！
2. サーバー実装完了！　テストコードも書いて、と。AマスタとBマスタとCマスタとDマスタとそれに紐づくEマスタとFマスタとGマスタとHマスタのダミーデータ用意して、あー面倒だけど書いとかないとな。え、Eマスタに紐づくIマスタとJマスタ足りない？　はい用意しますよ。え、更にIマスタからKマスタ参照してる？　あーもう、面倒だな。 あー、やっと動いた。あ、エラー処理動いてない。直しておこう。
3. クライアント実装完了！　実機確認！　何？　動かない？　ここが悪いのか。テストコードきちんと網羅してなかったな。直して、テストコード動かして、あ、ここミスってる。直して、動いたな。うん。
4. 動くようになった！　デプロイ！　実機確認！　何？　動かない？　いやテストコード動いてるけど……。あ、仕様間違えてる。直して、その分テストコードも直して。うん、動いた。
5. デプロイ！　実機確認！　何？　動かない？　あー、些細なミスしてんなこれ。テストコードの範疇外だから、でもまあ、すぐに分かったし、ここ直して、完了。
6. 出来た。ふぅ。

〜〜〜〜時が過ぎた〜〜〜〜

「その機能仕様変更ね」
「分かりました(サーバー側ここ直して、テストコード自体は余り変わらんな。まあ、そんな手間じゃない)」
2には戻らない。

要するに

　テストコードを書くのは面倒です。とても。そのコードを動かす為のDBデータを全て自らで用意しなければなりません。ユーザーを使うテストで、ユーザー登録処理などを事前にやっておいたり、クライアントで生成されるデータをこちらで入れてあげなければいけないといけない、などなどテストをする為には色々な障害があります。
　必要なデータが多ければ、テストをする以前に１時間以上の手間が普通に掛かる事さえも。
　でも、エラーが発生した時など、テストコードがあればコンソールなど動かさなくとも1コマンドを打つだけで簡単にコードに問題ないかを確認する事ができます。
　テストコードが動いているのにエラーが発生しているとなれば、それはテストコードが条件を漏らしているという事が逆に判明し、それ以外の部分で何かが発生しているのだとすぐに理解、注力する事が出来ます。
　最初に数時間、テストコードを書く事に時間を費やしておけば、エラーが起きたりしてもその対処がとても楽になるのです。

Railsでテストをする為に

　まずテストコードを書くと言っても、元となるのはそのアプリケーションのコードです。そのコードがスパゲッティコードだとテストコードも書けなくなってしまいます。

MVCをきちんと分けよう

　正直なところ、最もな事柄はこれに尽きます。
　MVCがきちんと分けられていないコードはとてもテストし辛いです。特に単体テスト。
　ControllerやViewに処理が書かれているとなると、その部分のコードをテストする為には、テストコードの中からAPIを叩かなくてはなりません。
　MVCそれぞれのテストはそれぞれだけで完結出来るようなコードを書きましょう。

メソッドを小分けにしよう

　メソッドを小分けにしておくと、それぞれでのテストが可能になり、仕様変更となった時に確認、保守が楽になります。

　そしてテストコードを書く時は。

面倒臭いけどやらないと後々もっと面倒になるからやる

　本当に。
　自分が書くのが好きじゃないって言うのもあるかもしれませんが、やらなければ後々もっと面倒な事になります。本当に。
　テストデータを数十の単位で作成しておかなければいけなかったり、吐くエラーの数だけ本当に正しく吐かれるのかを試すようにデータを弄ったりと。
　Rspec、FactoryBot(もうGirlじゃないんですね)を使っている分Railsのデフォルトのテスト機能よりは楽なはずでしょうが、それでも手作業の部分は膨大になりがちです。
　書いた事のない貴方も、後々楽になると信じて書きましょう。

　それでは、時には面倒だけれどより良いRailsライフを送る為に頑張りましょう。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

漫画やアニメなどの世界でちょくちょく見かける、拳圧だけで相手を吹っ飛ばすシーンについて考えてみたいと思います。

初めに

　お互い離れた場所にいるにもかかわらず、片方がその場でパンチするモーションをしたら、相手が吹っ飛んだ、のようなシーンはバトルがある漫画等ではそれなりに見かけると思います。今回の記事では、実際にこれを真似するにはどのぐらいのパンチ速度が必要なのかを考えてみたいと思います。

前提条件

　今回も、高校レベルの化学と物理によるザックリ計算を目標に、色々と簡略化・無視して考えていきます。
本日吹っ飛ばされていただくのは、
体重：60kg
吹っ飛ぶスピード：秒速5メートル
の方です。1秒で5メートルぐらい吹っ飛ぶので、結構痛いと思います。
（参考として空気の大砲で人を吹っ飛ばす動画を見てみましたが、秒速5メートルぐらいで吹き飛ばされた後、無傷で立ち上がっていたので、秒速5メートルならそこまで危険な速さではないと思います。）

準備計算

　まず、拳圧で吹っ飛ばされるのはどうしてかを考えます。これは拳で圧縮した空気の塊を飛ばし、相手にぶつけているからだと考えられます。
　そこで、空気の塊の重さを見積もりたいと思います。
空気を簡単のため、窒素8割と酸素2割で構成されているとします。窒素N2の分子量は28、酸素O2の分子量は32ですので、理想状態1mol(=22.4リットル)の重さは、
28*0.8+32*0.2=22.4+6.4=28.8グラム
よって空気1リットルの重さは28.8/22.4≒1.3グラムとなります。

空気のスピード

　ではまず、人を吹き飛ばす空気の速さを求めたいと思います。
人のパンチで打ち出せる空気の量は、パンチの際に腕が通過する部分程度であると考えられます。これをザックリ1リットルということにしましょう。1リットルの空気の重さは上述のとおり大体1グラム。これで60キログラムの人が秒速5メートルで動きだすので、運動量保存の法則から、空気の速さをvとすると、
(60*10³⁾ * 5 = 1 * v
v=秒速300キロ
ということが分かります。1秒間で東京から金沢まで行けるスピードです。
この時点で、既にやばそうですが、続けて腕の速度を求めたいと思います。

空気抵抗

　空気の塊が飛んでいく最中には、空気抵抗によってどんどんスピードが落ちていってしまいます。そのため、発射するときには、上で求めた速度よりももっと速くないといけません。空気抵抗をまじめに計算すると大学物理の範囲になってしまうので、上手いこと楽しようと計算したところ、空気塊の初速度が2*10⁸⁶⁴ [m/s]となり、光の速度を超えてしまい、さすがに間違っていると思うので、空気抵抗は割愛します。

パンチのスピード

　パンチする人も同様に体重60キログラムの人だとします。片腕の重さは体重の6%程度らしいので、この人の腕は3.6キロになります。（拳圧で人を吹っ飛ばせるならもっと腕がぶっといと思いますが…）
　前述のとおり、空気抵抗を無視して、空気の塊がそのままのスピードで向かっていくと仮定します。すると、パンチの速さをvと置けば、先ほどと同様に運動量保存を使って、
1*300*10³ = 3600 * v
v=300/3.6=83[m/s]
従って、パンチの速さは秒速83メートルとなります。これは時速300キロにもなります。調べたところ、ボクサーのパンチは時速30～50キロ程度だそうなので、
まさに人類を超越した高速パンチが必要になりそうです。

最後に

　今回の計算は、わざわざ人‐空気塊‐パンチという図式にしましたが、パンチで出した威力がそのまま人に到達する理想的な状態のため、人‐パンチでも同じ結果になります。実際には空気塊の速度減衰が必要になってきますが、高校物理の範疇を超えてしまうため、今回は省略しました。
　ただのパンチで人を5メートル飛ばしているような図式になってしまいましたが、それでも相当の速度が求められますね。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

　メロスは激怒した。必ず、かの30秒も掛かるAPIを高速化せねばならぬと決意した。メロスにはボトルネックがわからぬ。メロスは、クライアントエンジニアである。XCodeを使い、仮想iOSと遊んで暮して来た。けれどもボトルネックに対しては、人一倍に敏感であった。きょう未明メロスは電子の海を出発し、SSHで海外へ飛び、三千里はなれた此このシラクスのサーバーにやって来た。メロスには父も、母も無い。女房も無い。十六の、内気な二次元の妹と二人暮しだ。この妹は齢二十になるかの邪智暴虐の王を倒した勇者を花婿として迎える事になっていた。結婚式も間近かなのである。メロスは、それゆえ、泣きながらも仕事に励んでいたのだ。
　メロスには竹馬の友があった。セリヌンティウスである。今は此のシラクスのサーバーで、サーバーエンジニアをしている。その友を、これから不正に手にいれたroot権限で訪ねてみるつもりなのだ。久しく逢わなかったのだから、訪ねて行くのが楽しみである。歩いているうちにメロスは、サーバーの様子を怪しく思った。タイプがやけに重い。もう既に日も落ちて、あちらの時刻は暗いだろうけれども、全体が、やけに重い。のんきなメロスも、だんだん不安になって来た。セリヌンティウスの痕跡を発見し、何かあったのか、追跡した。二年まえに此のサーバーに来たときは、夜でもサーバーは穏やかで、軽かったはずだった。管理者からは中々その痕跡が分からなかった。メロスは両手でコマンドをゆすぶって追跡を重ねた。セリヌンティウスは、あたりをはばかるように、わずかながら痕跡を残していた。

#このAPIは、時間がかかっている

「なぜかかるのだ。」

//悪心を抱いている、というのですが、誰もそんな、悪心を持っては居りませぬ。ただ、コードがアレなだけです。

「たくさんのSQLをよんでいるのか。」

=begin
はじめはアクセスしたユーザーを。
それから、御自身の設定ファイルを。
それから、メモ化されていないマスタデータを。
それから、たくさんのユーザーデータを一つずつ参照して。
それから、新たに作成されるデータを念のため一つ一つバリデーションをかけて。
それから、キャッシュの更新を。
=end

「おどろいた。セリヌンティウスは乱心か。」

<!-- ユーザー数が急激に増えたことに加えて、仕様変更が重なったことが原因。
このごろは、それによってぐちゃぐちゃになったAPIそのものの振る舞いもおかしくなっている。
レスポンスが30秒を超えることも全くおかしくない。
-->

　コメントを読んで、メロスは激怒した。「呆れたAPIだ。生かして置けぬ。」
　メロスは、単純な男であった。アクセスログを残したままで、のそのそソースのディレクトリにはいって行った。たちまち彼は、問題のAPIを読んだ。調べて、メロスの脳裏からはデータベースにインデックスが貼られていない疑惑が出て来たので、胸騒ぎが大きくなってしまった。メロスは、セリヌンティウスに直接電話をした。
「このデータベースは何をするつもりであったか。言え！」暴君メロスは静かに、けれども威厳を以もって問いつめた。そのセリヌンティウスの顔は蒼白で、眉間の皺は、刻み込まれたように深かった。
「元からそうだったのだ」とセリヌンティウスは悪びれずに答えた。
「元から？」メロスは、憫笑した。
「仕方の無いやつじゃ。おまえには、わしの孤独がわからぬ。」セリヌンティウスは悲しそうに返した。
「言うな！」とメロスは、いきり立って反駁した。「人の心を疑うのは、最も恥ずべき悪徳だ。セリヌンティウスは、ユーザーの期待さえ疑って居る」
「疑うのが、正当の心構えなのだと、わしに教えてくれたのは、おまえだ。自分のコードは、あてにならない。コードは、もともとバグのかたまりさ。信じては、ならぬ。」セリヌンティウスは落着いて呟き、ほっと溜息をついた。「わしだって、平和を望んでいるのだが。」
「なんの為の平和だ。自分の地位を守る為か。」こんどはメロスが嘲笑した。「罪の無いサーバーを熱くして、何が平和だ。」
「だまれ」セリヌンティウスは、さっと顔を挙げて報いた。「口では、どんな清らかな事でも言える。わしには、コードのバグの奥底が見え透いてならぬ。おまえだって、いまに、威力業務妨害になってから、泣いて詫びたって聞かぬぞ。」
「ああ、セリヌンティウスは悧巧だ。自惚れているがよい。私は、ちゃんと死ぬる覚悟なんてない。さようなら」
ガチャ。

　そんな事にならないように負荷テストはちゃんとしましょう。
　その為のサーバーの性能を計るツールとして、JMeterというものがあります。

JMeterとは

　一言で言えば、サーバーに負荷を掛け、パフォーマンスを測定する為のオープンソースです。
　これを使えば、任意のAPIに対して秒間N回のリクエストを投げたりどの位の同時接続数までなら快適に動作するのか、どのAPIがボトルネック(ボトルネックではなく、ボルトネック、そんな風に呼んでいた時期が俺にもありました)なのかなど、様々な事を調べる事ができます。
　それで、JMeterの基本的な扱い方に関しては色んな所に書いてある為、実際のテスト時に、役に立つような事を上げていきたいと思います。

CUIでの実行時に色々と条件を変えてテストしたい

　基本的にJMeterでちゃんと負荷テストを行う時は、GUIからの実行ではなく、CUIからの実行になります。GUIで行わない理由は、そのGUIの処理そのもののせいで、より正確なデータが出力されないという事が理由です。
　その時に、RampUpやSleep時間、メインスレッド数など様々な条件を変更して負荷をより正確に測っていく事もあると思いますが、その色々の設定を変更する際に、
・GUIを同時に開いてその設定を書き加えて、保存してCUIから実行とか、
・テスト計画ファイルであるJMXファイルを直接弄って編集(JMXファイルの中身はXMLなので、修正しようと思えばできる)とか、
　そういう事は面倒臭いです。上記はある程度楽かもしれませんが、GUIを使えない別サーバーからの実行とかそんな事もありますし。
　幸い、JMeterにはCUI実行時にコマンドライン引数を参照する仕組みがあるので、それを活用しましょう。

　この上記のように、変数を指定する部分を${__P(変数名)}とする事によって、CUI実行時にそのコマンドライン引数を取ってきてくれるようになります。
　コマンドライン引数の指定の仕方は、

-J変数名=値

　といったように、文頭に-Jを付けて後は変数名と値を=で結ぶだけです。
　上記のように、スレッド数(client)、Ramp-Up期間(ramp_up)、sleep時間(sleep)、メインループ回数(main_loop)を指定したいときは、以下のようになります。

>path/to/jmeter -n -t execute_jmeter_source.jmx -l output_result.jtl  -Jclient=100 -Jmain_loop=20 -Jsleep=1000 -Jramp_up=300

※ -n : 非GUIモードで起動, -t : 実行ファイル名を指定, -l : 結果ファイル出力先を指定
※ Ramp-Up期間の単位はsec(秒)で、sleep時間の単位はmsec(ミリ秒)です。

　……え？　こんな長いコマンド打つの面倒？
　……シェルでも組みましょうか。

データをエクセルに纏める

　上記のコマンドを終えると、output_result.jtlという結果ファイルが吐き出されます。
　ただ、中身としてそれは実行した一つ一つのリクエストに対するデータがずらりと並んでいるCSVファイルであって、統計的にはデータを見れません。
　HTMLでレポートを出力してくれるオプションもあるのですが、それではテストを複数回行った時の差分も分かりづらいです。
　では、どうしたらいいか。
　取り敢えず、GUIでJMeterを開いて、統計レポートの部分を出しましょう。

　そこで参照で、出力されたjtlファイルを入れてやれば、リクエストの種別毎に平均値や中央値、90%lineなどを計算した上で結果をまとめてくれます。

※参照した時に元からそのGUIで実行したデータや前に参照したものがあると、それを上書きするのではなく加算してしまうので、必ず空っぽにしておきましょう。
　これなら、どのAPIが問題なのか等が分かりやすく見えてきました。
　そして、Save Table DataでCSVに出力しなおせば、ちゃんとリクエストの種別毎にデータをエクセルに纏める事ができます。
※文字はUTF-8で保存されるので、環境によっては文字化けします。なので、適した文字列にエンコードしなおしてあげる必要があります。Macなら、CSVファイルをテキストエディットで開いて複製、その複製を保存する時に文字コードをUTF-16に変換、とか。

負荷試験で掛かる時間を計算する

　CPUが100%になっていない範囲、待ちなどが発生していない前提の話になりますが、負荷試験で掛かる時間は概算する事ができます。
　まず、軽くテストを流してみて、メインループ内での1つのリクエスト単位での平均レスポンス時間を出します。
　そうすると、

1回のメインループで掛かる時間 ＝ メインループ内のリクエスト数 × (メインループ内での1リクエスト辺りの平均レスポンス時間 + Sleep秒)

　と計算できます。そして、メインループ外の処理がメインループに比べて小さければ、その1回のメインループで掛かる時間にメインループ数を掛ければ、それがスレッド一つで掛かる時間となります。
　そして、最後に影響するのがRamp-Upです。
　Ramp-Upは指定した数のスレッド全てが負荷テストを実行開始するまでの時間です。
　スレッド数を10、Ramp-Upを60(秒)と設定した場合、6秒間に1スレッドずつテストを開始し、そして60秒が経った時に全てのスレッドが実行されている状態となります。
　そこから考えると、

負荷試験に掛かる全体時間 = Ramp-Up + 最後のスレッドに掛かる時間

　となります。そして、待ちが発生しない限りは最後のスレッドに掛かる時間と1スレッドの全体時間は変わらないので、

負荷試験に掛かる全体時間 = Ramp-Up + 1スレッドの全体時間
　　　　　　　　　　　　 ≒ Ramp-Up + メインループ数 * 1回のメインループで掛かる時間
　　　　　　　　　　　　 ≒ Ramp-Up + メインループ数 * メインループ内のリクエスト数 × (平均レスポンス時間 + Sleep秒)

　と、出せます。
　これでずっと画面に張り付いていなくとも、大体終わる時間がわかって、終わった後長らく放置しているような事もなく、他の事を出来たりします(当たると嬉しいのでそういう意味でも計算は楽しい)。

重い原因を調べる

　さて、試験結果を出せるようになったところで、それが何故重いのかを調べる必要があります。
　コードが悪いのか、サーバーの性能が足りないのか、それともサーバーの設定が悪いのか、IO負荷が酷いのか、待ち状態が発生しているのか、そもそものテストの条件が悪いのか……。
　そんな時に役に立つのが、監視ツールです。監視ツールを駆使すれば、メモリやCPUの消費量、局所のみならず全体の軽量化にも大きな役割を果たせます。
　まあ、こちらも調べれば色々と無料から有料のものまでたっぷりと出て行くのでそこからプロジェクトと相談して何をどう使っていくか決めていくべきでしょう。
　後、簡単にメモリやCPUの状況を調べたいなら、その負荷を掛けている実サーバーでsarやらpsやらvmstatやらのコマンドを打てば色々と出せます。

実際触ってみてなどの所感

　JMeterを触って2ヶ月ほどが経ち、こうして社内ブログに載せてみた訳ですが、少々触れてみた感想を。

編集手段が専用のGUIしかない事が辛い

　レスポンスを受け取ってそれを次のパラメータの値として送る、とかもやったりしたのですが、それを自分はjavascript(複数の言語から選べる)で値をいじったり保存したりとして実装しました。
　ただ、エラーが起きてもそれがどこの何行で起きているのか表示してくれなかったり、(postやputメソッドを送った時に形式をちゃんとヘッダの情報に付与しないときちんとパラメータが送れない事を知らなくて長い時間悩んだり)、動的にパラメータを作成しようと思ったらJavaオンリーで色々触れなくてはいけない事を知ったりと、色々と大変でした。

気づかなかったボトルネックに気付く事が出来た

　ここはボトルネックじゃないだろーと思いながらもテストしてみたら酷く重い事になって、よくよく調べてみたら、データの紐付けがきちんとしていなくて取得するのに時間が掛かっていた、などという事もあったので盲点からのコードの見直しもできるようになります(全APIのリクエストを実装するのは……大変です)。

　では、本番でパンクしないように適切な設計を考えながら負荷テストをしましょう。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Googleデータポータルでヒートマップ・棒グラフを設定するTIPSです。エクセルなら簡単に作れるヒートマップやセル内の棒グラフですが、Googleデータポータルではどこで設定すればいいかわかりにくい。でも、一度知れば簡単なのでその方法をご紹介します

この記事でまとめられていること

こんにちは。株式会社アピリッツでアナリストをしているssekiです。

前回からGoogleデータポータルを使っているときの細かなつまづきポイントを紹介しています。
今回もそんな不満をかなえるTIPSのご紹介です。まずは前回のおさらいですが、こちらの表をご覧ください。

　▲参照元別のセッション数およびCV数を比較する表（Googleデモデータを利用）

というわけで、早速ですが今回紹介するのはヒートマップと棒グラフの設定方法になります。

ヒートマップ・棒グラフとは

設定方法の共有の前に、ヒートマップ・棒グラフを知らない方がいるかもしれないので前提からお話しします。
簡単に言うと、両方とも「数値では一目でわかりにくい表を、可視化してわかりやすくするグラフ」の一種です。
ただ、可視化の手段に応じて名前が変わります。

まず、ヒートマップでは可視化のために色のグラデーションを使います。
例えば、色が濃いほど数値が高く、色が薄ければ数値が低いといったルールにすれば、どの行の数値が高いか一目瞭然です。
ただし、細かな色の違いはわかりにくいため、変化が激しいときに使うのが一般的です。

次に、棒グラフでは棒の長さで数値を表します。
端的に言えば、棒が長いほど数値が高く、棒が短いほど数値が低いというわけです。
ヒートマップに比べてより細かな差も区別しやすいのですが、一方で変化が激しすぎると小さな数値の棒が見えなくなります。
そのため、差が大きくなりすぎない数値や、比較的差が開きにくい「割合」などで使われることが多いです。

データポータルでのヒートマップ・棒グラフ設定方法

データポータルで直接データに関わらない、見た目を整える際は「スタイル」を用います。
設定場所はこちら。

　▲データポータルレポート画面で表を選択した際の右側
青丸で囲った「スタイル」をクリックし、下にスクロールすると、赤丸で囲った「列」という項目があります。
列には番号が振られていますが、これは表に設定した指標を左から順に数えた時の番号と一致します。
今は列１にセッション、列２にセッション（全体の割合％）を設定しているので、次のように変更します。

　▲各列にヒートマップと棒グラフを設定
列１をヒートマップ、列２を棒グラフに設定しました。
すると右側にペンキマークが出てきます。こちらからそれぞれの色を変更できます。

また、棒グラフの場合はチェックボックスで以下の表示を切り替えることができます。

• 番号を表示 ⇒棒グラフに加えて元の数値を表示できます。
• 目標を表示 ⇒目標値を設定すると線が引かれます。目標を達成しているかどうかを判断しやすくなります。
• 軸を表示 ⇒棒グラフの長さに応じた軸を表示します。 上記のうち、「番号を表示」にチェックを入れて色を整えたものがこちらになります。  　▲参照元別にセッション数と構成比を視覚的に比較しやすくした表

だいぶ最初の表に近づいてきましたね。これでヒートマップと棒グラフを設定できるようになりました！

まとめ：この機能はどんな人におすすめか

この機能は無くても分析上困るものではありませんが、知っていると視覚的にわかりやすい表を作成できます。
レポートを他人に共有したり、素早く数値の意図を判断するためにはこうしたテクニックが必要になるかと思います。
細かな仕様を学び、ワンランク上のデータポータル使いを目指しましょう！

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Googleデータポータルでの構成比の出し方です。エクセルなら簡単に作れる構成比（全体に対する割合が何％か）ですが、Googleデータポータルでは少しテクニックが必要。慣れてしまえば簡単なのでその方法をご紹介します。

この記事でまとめられていること

こんにちは。株式会社アピリッツでアナリストをしているssekiです。

Googleデータポータルを使っていると細かな部分がエクセルと違っていて、つまずくことありますよね。
今回はそんな不満をかなえるTIPSのご紹介です。まずは、こちらの表をご覧ください。

　▲参照元別のセッション数およびCV数を比較する表（Googleデモデータを利用）

「エクセルだったらこれくらいできるよ・・・」って感じなんですが、今回はデータポータルで痒い所に手が届くTIPS紹介なのでGoogleデータポータルを使って作ります。

今回紹介するのは「セッション（全体の割合％）」という名の列、つまりセッション数の構成比の作り方になります。

セッション数の構成比を作るには

簡単な話、エクセルなら「個々のセッション数÷合計のセッション数」で計算すればOKです。
しかし、Googleデータポータルにはそんな計算機能がない（あるかもしれないけど複雑な計算式を立てなければいけない）ので、データポータルがデフォで用意している機能を使います。

その名も、「解析関数」！！！

なんだか大仰な名前ですが、ほぼワンステップでできる便利な機能です。
設定場所はここ。

　▲データポータルレポート画面で表を選択した際の右側

「123」と書いてある部分をクリックすると、次のポップアップが表示されます。

　▲指標のポップアップ表示
赤丸で囲っている部分に「解析関数」とあるのがわかるでしょうか。
こちらを選択して、「全体に対する割合」に変更します。
タイプも自動で「%」に変更されるので、ついでに名前も変更しておきましょう。

　▲名前・タイプ・解析関数を変更した状態

ここで、解析関数の中身ですが、計算方法に応じて次の３種類があります。

• 全体に対する割合 ⇒「個々の値÷全体の値」を計算。構成比を出すのに使えます。
• 合計との差異 ⇒「個々の値ー全体の値」を計算。おそらく合計値が0になるような計算で使うのかと思います。
• 合計に対する割合 ⇒「個々の値÷全体の値ー１」を計算。用途についてはよくわかりません・・・。

後ろ２つについてはユースケースが思いつかないのですが、おそらく何かに使えるときがくるはず・・・。
機会があればまた記事にします。

ここまでで、表はこのようになっています。

　▲参照元別にセッション数の構成比を表した表

セッション数の構成比を出すことは、できました。
ただし、元のセッションに関する指標が表からなくなってしまうので追加しておきましょう。
※指標フィールドからは消えていないので、普通に追加すればOKです。

　▲参照元別にセッション数と構成比を比較した表

お疲れさまです。これで構成比が作れるようになりましたね！

まとめ：この機能はどんな人におすすめか

普段エクセルで表作成をしていると、構成比を入れるのがデフォになることがしばしば。
いざデータポータルでやってみたらやり方がわからない・・・。なんて人も多いのでは？
今回はそんなエクセルマスターな人におすすめの機能でした。

次回以降も、冒頭の表を作るためのTIPSを紹介していきます。
ご期待ください！

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Photoshopの便利機能、アクションの使用方法

アクションとは

アクションは、Photoshopに搭載されている機能の一つで行った動作を記録し、好きな時に繰り返し利用することができる機能です。
なんらかの媒体で画像を使用するとき、用途に合わせて加工をしたり指定のサイズに揃える必要がある場合がほとんどだと思います。
ものによっては膨大な量を作業しなくてはなりません。

そんなとき、一連の動作を自動で行ってくれるアクション機能を用いると作業効率を大幅にあげることができます。

アクションの作成

ねこの画像を用意しました。
こちらのねこの画像を加工し、書き出すまでのアクションを作成します。

使用バージョン：Adobe Photoshop CC 2017

1：新規アクション

アクションパネルから[新規アクションを作成]ボタンをクリックします。
(アクションパネルがない場合ウィンドウタブから呼び出します)
これから行う動作のアクション名を付けて[記録]をクリックします。

２：アクションの録画

[記録]をクリックすると録画マークが赤く光ります。
この間、行う動作ひとつひとつが記録されます。


記録したい動作を行い、[OK]を押します。(画像では色調補正を行っています)


[記録を中止]ボタンを押します。
これで、以降の動作は記録されません。

複数の処理を行いたい場合は、続けてそれぞれの動作の記録を行ってください。
記録を繰り返し、合計4つのアクションを記録しました。

アクションの詳細は、項目の＞マークをクリックすることで確認ができます。
詳細をさらにクリックすることで内容を変更することも可能です。
必要であれば調整を行ってください。

これでアクションの作成は終了です。

アクションの実行

同じ画像処理をしたい画像を読み込み、実行したいアクションを選び[選択項目を再生]をクリックします。このワンステップだけで画像の処理は終了です。


書き出しのアクション記録時に指定したフォルダ先を確認しましょう。

無事に画像が書き出されていました。
アクションを利用することで、同様の画像をあっという間に処理することができます。
処理したい画像の数だけ読み込み→アクションの実行を繰り返していきましょう。

おわりに

繰り返しの動作を行う際にアクションは非常に役立ちます。
画像処理に限らず、よく行う動作はアクションを記録しておきましょう。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

VirtualBoxで作った仮想環境を新PCに移行する際、 一部の環境で起動できない問題が発生したので解決メモ。 　

人からもらったディスクイメージを元に
差分ストレージとして構築していたため、
その大本のイメージも新PC上で同じパスに置かないとダメだよ、
というエラーが発生しました。

.vboxファイルの中身だけ書き換えても
仮想メディアマネージャーには反映されないし、
仮想メディアマネージャーから変更を行おうにも
元ファイルがないのでエラーになります。
　

解決方法は以下
　1. 新PCにも同じ場所に大本のディスクイメージを設置する
　2. 旧PCの仮想メディアマネージャーでディスクイメージの場所を移動後、
　　新PCに移行する
　
　

解決方法1. 新PCにも同じ場所に大本のディスクイメージを設置する

この方法が一番シンプルです。
旧PCと同じ場所に設置して起動できるか確認。
起動できたらそのまま使ってもよいし、場所を移動したい場合は2を参照↓
　
　

解決方法2. 旧PCの仮想メディアマネージャーでディスクイメージの場所を移動後、新PCに移行する

ドライブが存在しない等で1の方法が取れない場合は、
いったん旧PCの方でディスクの場所をCなどに移動してから移行します。
　

1. ファイル＞仮想メディアマネージャーを開く
2. ハードディスクを選択し「コピー」で移動したい場所に作成 　※「変更」からは場所の変更はできない
3. 設定＞ストレージで新しく作ったディスクに付け替え
4. 新PCに、VirtualBoxのファイルを丸ごと移行（環境設定＞一般の「デフォルトの仮想マシンフォルダー」内にあるファイル）
5. 新PCに、2で作成したディスクイメージを移行（旧PCと同じパスに設置）
6. 新PCで仮想マシンフォルダにあるvboxファイルダブルクリック等してVirtualBox起動
7. 仮想マシンが読み込まれてるはずなので起動確認
8. スナップショットも読み込まれているか確認
9. さらに場所を移動したい場合は再度2の手順へ 　

　
スナップショットが読み込まれていない場合は、
.vboxファイルをテキストエディタで開いて、
＜HardDisks＞内のlocationで指定されてるパスを確認。
違ったら修正して保存→VirtualBox起動

　
　
今後のPC移行を考えると2で指定する元ディスクの場所は
仮想マシンフォルダ内に置いておくのがいいですね。
うっかり最初に変なところに置いたまま構築してしまったので
非常に面倒でした。。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

git stash -u で.gitignoreに記述されているディレクトリやファイルが消えてしまうケースがあるようです。

git stash -u

新規作成されたファイルなどuntrackedなファイルも
まとめてstashしてくれる-uオプションですが、
挙動に注意する必要があるとのことです。
　

ローカル環境でrailsを使っていて、
知らないうちにbundlerが使えなくなってることがあり、
しばらく謎＆困っていたのですが、
どうやらpre-pushで走らせていたシェルスクリプト内で
git stash -uを使っていたのが原因のようでした。
　

bundle install もエラーが出て、
よくみるとvendor/bundler配下のrubyのファイル群がごっそり消えていました。
　

調べてみると.gitignoreの記述の仕方によって
ここに書かれているディレクトリやファイルが消えてしまうとのこと。

結局スナップショットからvendor/bundler配下のファイルを復元して事なきを得ましたが
git管理外にしたファイルが消えてしまってはたまったもんじゃないないですね。。
　

git stash を使うときは、一度addしてから

git stash save "コメント"

とした方がよさそうです。
皆さんもご注意ください。
　
　

参考
https://i-beam.org/2015/11/12/124405/
https://qiita.com/yamamoto_hiroya/items/f4d6922e823291e6e790

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

クローラーとはWEB上に掲載されているテキストや画像や音声データを収集するロボットのことをいいます。

クローラーとは

クローラーとはWEB上に掲載されているテキストや画像や音声データを収集するロボットのことをいいます。html上のaタグをもとにクロールするURLを取得し情報を取得するのでクロールさせる場合はページ上のどこを取得するか指定する必要があります。

heritrixとは

クローラーするソフトはたくさんありますが、今回はheritrixを使います。heritrixはspringをもとに作られているオープンソースのクローラーです。ブラウザ上で設定や実行などができるので割と便利です。現在バージョン3系まで出ており、動かすためにはjava6以上が必要です。

導入

ホームーページの導入ガイドは3.1ですが、バージョン3.2が出ているので今回はそちらを使います。
環境:
Vagrant + VirtualBox
OS:CentOS Linux release 7.4.1708 (Core)
java:1.7.0_80

ソースの取得

まずはこちらから環境にあったものを持ってきます。

wget http://builds.archive.org/maven2/org/archive/heritrix/heritrix/3.2.0/heritrix-3.2.0-dist.tar.gz
tar zxvf heritrix-3.2.0-dist.tar.gz

パスやメモリの設定

適宜設定を行います。

export JAVA_HOME=/usr/java/jdk1.7.0_80
export HERITRIX_HOME=/home/vagrant/heritrix-3.2.0
chmod u+x $HERITRIX_HOME/bin/heritrix
export JAVA_OPTS=-Xmx1024M

起動

仮想環境の場合は、-bオプションでipを指定します。
自分はvagrantなのでゲストのipを設定

$HERITRIX_HOME/bin/heritrix -a admin:admin -b 192.168.XX.XX

※javaのバージョンが新しすぎると以下のようなエラーが出るようです。自分はjavaのバージョンを下げることで対応しました。

Exception in thread "main" java.lang.NoClassDefFoundError: sun/security/tools/KeyTool
  at org.archive.crawler.Heritrix.useAdhocKeystore(Heritrix.java:438)
  at org.archive.crawler.Heritrix.instanceMain(Heritrix.java:319)
  at org.archive.crawler.Heritrix.main(Heritrix.java:189)
Caused by: java.lang.ClassNotFoundException: sun.security.tools.KeyTool
  at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
  at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185)
  at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
  ... 3 more

クロールの実行

ブラウザにアクセス

https://192.168.XX.XX:8443/enginebasic認証を聞かれます。ユーザー：adminパスワード：admin

↓の画面が開きます

jobの作成

クロールをするためのジョブを作成します。
↓の赤枠の部分に名前を入れてcreateボタンを押します。

job画面へ遷移

↓の赤枠の部分が作成されるのでクリック

↓の画面が開きます

編集

最低限クロールを実行するために、xmlファイルを設定しなくちゃいけない箇所があります。
画面上部のConfigurationをクリック
↓の画面が開きます

metadata.operatorContactUrlの編集

クロールしたページでなにかトラブルが起きた用に、ページの管理者がクローラーの管理者にコンタクトをするためのページを指定します。
↓の赤枠の部分

beanタグ(id=”longerOverrides”)の編集

クロールのシード（開始地点）になるURLです。
↓の赤枠の部分を編集

実行

ジョブのトップ画面で
build→checkpoint→launchの順番で実行すれば実行は可能

結果

実行結果は↓に出力されます。

おわりに

データを取得するためにはまだまだ設定をする必要がありそうです。今後調べていきます。

参考

・ホームページ
https://webarchive.jira.com/wiki/spaces/Heritrix/overview

・Webクローラ「Heritrix」を使ってみる
https://qiita.com/megu_ma/items/26ae5937ca4362ad767b

・国立国会図書館 インターネット資料収集保存事業
http://warp.da.ndl.go.jp/contents/reccommend/mechanism/mechanism_heritrix.html

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Micro Hardeningの記念すべき第一回開催に参加して全13チーム中 4位だったのでHardeningをダイレクトマーケティングしていきたい。

TL; DR

Micro Hardeningは楽しいので参加しよう。

ハードニングって？

Hardening ProjectはWASForum主催のセキュリティに関する実践対応力を総合的に競うコンペだ。参加者は架空のECサイト運用者となって延々と押し寄せるインシデントに対応する。つまり、攻撃者が様々な方向から攻撃し、複数のサーバがダウンし、各種のプロセスは停止し、トップページは改竄され『Hacked 🙂 』とか書かれ、帯域はサチり、顧客からの問い合わせメールが山と積もる。

参加者はチームとなってこれに対応し、攻撃を検知し、対応策を講じて、改竄されたページを発見しては戻し、ダウンしたサーバを復旧させ、いつの間にか入ったウィルスにも負けず、有料セキュリティソフトの導入を検討し、障害の報告書を書いて提出し、記者会見を開いて状況を説明しなければならない。ちなみにどれも本当にやる。

Micro Hardening

自分が今回参加しに行ったハードニングはMicro、つまりフルのハードニングに対するミニ・ミニ版だ。フルのハードニングは二日間ほどフル日程で競技を行うが、それより小規模なMini Hardeningは3-4時間ほど。そして更に小さいMicro Hardeningは1時間未満で終わる。ちなみにMicroは今回が初の開催らしい。

もちろん、せっかく土日にやってきて1時間だけで終わるのは寂しいので繰り返し何度も行う。なお、攻撃パターンは毎回同じなので敵が出てくるパターンを死にながら覚えるタイプのアクションゲームと大体同じだ。

また、競技時間の短さ以外の特徴としてMicro Hardeningでは技術以外の対応はしなくてもいい。つまり、他のハードニングとは違って障害報告書を書いたり顧客のメールに返信したり記者会見はしなくていい。こういうところでも参加するハードルは非常に低い競技だといえる。(我々は障害報告書のテンプレートを見るだけで色々思い出して複雑に気持ちになれる)

さて、実際にどんなことをやるのかというと、まず構築済みの環境がぽいっと渡されるのでポートフォワーディングなどしながらSSH接続する。

それぞれの環境ではECサイトが稼働しており、このECサイトへボットが定期的にアクセスして何かしらを買っていく。そして、この受注金額がスコアとして加算されていくので我々はボット様がお買い物に不自由されないよう保守していればいい。

しかし順調だったグラフの伸びも突然止まる。ページ改竄、DoSアタック、SQLインジェクション。プロセスは落ちるわ、不思議な力(脆弱性)によって見知らぬファイルが作られるわで忙しい。時間こそ僅かに45分だが、この間に５，６回ものの攻撃を受けるのでその度に対処して復旧しなければならない。

なお仮に購入操作に問題はなくとも復旧までの間はボットも買い物をしない。Hacked 🙂 と書かれたトップページのECサイトで買い物をする豪の者はいないのだ。

面白いところ

まず、この競技の良いところは「理解/把握したらすぐ次のセットで対応を試せる、改善できる」ところだ。普通のハードニングでは「あぁ〜あの時こうしていればぁ！」と悔しい思いをしてもすぐにリトライはできないがMicro Hardeningならすぐにリトライ出来る。

スコアが常に可視化されてスクスクと伸びていくのを見るのも楽しい。何故か止まったらすぐに原因を調べて対処だ。あまり他の参加者と競う雰囲気ではなく、前回の自分たちのスコアを乗り越えられるかどうかという達成感に重点が置かれる。

ひとくちレポート

チームは会場入りした順番にランダムで決定され初対面のメンバー同士だったものの、Slackや口頭で適宜コミュニケーションを取って各自が得意な部分を受け持ちながら競技を進められた。ISUCONなど高速化系の競技でMySQLやアクセスログ周りがいくらか明るくなったのでもっぱらその辺をやっていた。

結果は序文にも書いた通り13チーム中の4位とまぁまぁの高得点を達成。特に最終セットでは全てのインシデントをきっちり対応しきったつもりだったが、いくつかのボーナス得点を獲得できていなかったらしくトップとはいくらか差の付いた結果になった。

とまぁ残念ながらインシデントや他の参加者について詳細なことは書けないが、とりあえずMicro Hardeningはハードニングの雰囲気をつかむにはとても良い入り口なので是非みんなも参加してみてほしい。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

ベジェ曲線というものをご存知でしょうか。
ゲームなど、コンピュータ上できれいな曲線を表現することができる式です。
この記事ではそのベジェ曲線をゲームに利用してみます。

＊ベジェ曲線は、その線（軌道）を描くのに開始地点と終点以外の制御点を1つ以上使うのですが、この記事では個人的な扱いやすさと動きから開始と終点含めて計4つの座標を使用します。

実際の計算式と動き

下記の式でTimeを0.0f ~ 1.0fまで動かすことで表現できます。

position = (1.0f - Time) * (1.0f - Time) * (1.0f - Time) * 開始地点 +
            3.0f * (1.0f - Time) *(1.0f - Time) * Time * 制御地点1 +
            3.0f * (1.0f - Time) * Time * Time * 制御地点2 +
            Time * Time * Time * 終了地点;

＊このgifでは左下の地点から時計周りに 開始地点,制御地点1,制御地点2, 終了地点です。

実用

シューティングの弾や取得したアイテムの取得演出などに使えると思います。
線形補間とかでオブジェクトの座標を設定してもいいですがベジェを使うと自然に不規則な感じが出てかっこいいです。

制御地点を変えるだけでも動きにかなりのバリエージョンが出せますし、
この記事では2次元的な動きしかお見せしていませんが当然1次元、3次元の動きにも使えるので色の変化やカメラの動きなどに使ってもいいかもしれません。

おわりに

ベジェ曲線について軽く調べると..
・N 個の制御点から得られる N − 1 次曲線である。
・2次ベジェ曲線 (Quadratic Bézier curve)、3次ベジェ曲線 (Cubic Bézier curve)などがある
.etc

どうでもいい上によくわかりませんが、ゲームのオブジェクトの動きに使おうとしてる自分的には周りに伝わる呼び方と結果を得られる式だけ理解できればそれでいいです。
仕組みがわからなくても一度使ってみると直感的に使えてとても便利だと思うので一度使ってみてはいかがでしょうか。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

検索アナリティクスから検索クエリの一覧表を見ると、そのワードで検索した際のGoogle検索画面にリンクする機能になっています。ですが、データポータルではテキスト状態がデフォルトなため、このリンクがなくなってしまいます。今回はHYPERLINK関数などを駆使することで同様のリンクをデータポータルレポートに反映可能にする方法をご紹介します！

この記事でまとめられていること

こんにちは。株式会社アピリッツでアナリストをしているssekiです。
前回の記事で、「データポータルを使ってサーチコンソールの検索クエリデータを1,000件以上取得する方法」をご紹介いたしました。
もちろん、ご紹介した方法で十分に使えるのですが、一点だけ気になるところが残ってしまうのです。
検索クエリが直接Google検索へリンクできなくなってしまうという点です。

ある検索クエリが実際にどんなニーズで検索されているのかを知るために、検索結果を見ることは重要です。
でも、わざわざ検索窓にコピペして調べるのは億劫ですよね・・・。

ということで、今回はデータポータルレポートでも検索クエリをGoogle検索にリンクするテキストリンクに変更する方法をご紹介いたします。

サーチコンソールにおける検索クエリリンク

すでによく使われている方には今更になってしまいますが、冒頭で伝えた検索クエリリンクとはどういうものなのかを説明します。

※情報保護のため、検索クエリを黒塗りしています。
左の画像はサーチコンソールの検索クエリ表です。情報保護のため黒く塗りつぶしてある部分に検索クエリが表示されます。この検索クエリGoogle検索結果へのテキストリンクとなっており、クリックすると右図のような画面に移動します。

冒頭で述べたように、キーワード毎にどんなニーズがあるのかを知りたいときには役に立つ機能ですが、データポータルではテキストとして表示されるためデフォルトでは機能が失われた状態になります。

データポータルで検索クエリをリンクにする方法

それでは、実際にハイパーリンク化する方法を見ていきましょう。
まずは検索クエリがディメンションに設定された表を用意します。

デフォルトで用意されている「Query」はテキストデータのためリンクしません。
そのため、計算フィールドを使って新しいディメンションを作成します。
今回使う関数は「HYPERLINK」と「CONCAT」です。実はこの関数、以前の記事でご紹介しています。
なので、今回は細かい説明は省略して実際の計算式だけ紹介します。

HYPERLINK(CONCAT("https://www.google.com/search?q=", Query), Query)

はい。これで新しいディメンションができました。
あとは、今作ったディメンションに切り替えて表示するだけです。


無事テキストリンク化し、サーチコンソールの時と同様にGoogle検索結果へハイパーリンクさせることができます。

番外編：Yahoo！およびBingの検索結果にリンクさせる方法

先ほどの計算式を応用すると、Googleのみならず様々な検索エンジンの検索結果にリンクさせることも可能です。
例えば、Yahooの検索結果にリンクさせたい場合は計算式をこのように変更します。

HYPERLINK(CONCAT("https://search.yahoo.co.jp/search?p=", Query), Query)

同様にBing検索結果の場合、計算式はこのようになります。

HYPERLINK(CONCAT("https://www.bing.com/search?q=", Query), Query)

お判りいただけたでしょうか。CONCAT()の中身がリンク先になるように「Query」の先頭につけるURLを、各検索エンジンのURLに変更しただけです。
技術としては簡単ですが、YahooやBingの検索結果にワンクリックでリンクできるのは便利ですよね！

なお、クリック数などはサーチコンソールデータのためGoogle検索のデータしか表示されませんのであしからず・・・。

まとめ：この機能はどんな人におすすめか

今回はHYPERLINK関数とCONCAT関数を用いて、検索クエリをテキストリンク化する方法をご紹介いたしました。
前回の検索クエリを1,000件以上取得する方法と合わせて、ウェブマスターに有用な機能かと思います。

また、番外編でも扱ったようにYahooなどの他検索エンジンにおいても応用できるのは便利ですが、この他にも自社のサイト内検索結果に応用するなど様々な使い方がありますので、必要に応じてご活用してみてください。