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

Unity上でテクスチャデータをめちゃくちゃ拡大して表示させた際に発生する色のにじみの対処法です。

　Unity上でテクスチャデータをめちゃくちゃ拡大して表示させた際に発生する色のにじみをなるべく目立たないようにする対処法についてまとめました。
　例としてあげる環境ではテクスチャ（512px×512px）をSpriteModeのPixelsPerUnitを0.5に設定し４倍のサイズで表示させています。更にテクスチャに回転処理をかけUnity上に表示させています。今回はテクスチャを作るために倍以上あるサイズの元のイラストデータをテンプレートに合わせてPhotoshopで縮小や回転をかけています。

にじみ状態パターン①線がぼける

　Photoshopで縮小や回転をかけると、形が変わってもある程度自然に見えるように自動的に色の処理が行われます。そのため上記のイラストもテクスチャ用に縮小したところ、下記の左のテクスチャ画像のように色がなじむように隣同士の色が混じり合った部分が発生しています。こちらをそのままUnityに組み込んだ結果右のようなぼんやりとぼかしのかかったような表現になってしまいます。

　この場合は色の混ざり合っている部分を隣り合ったどちらかの色の単色でに塗りつぶすことではっきりとした境界線になります。注意点はななめになっている部分です。単色で塗りつぶすとはっきりとはするのですがやりすぎてしまうとカクカクとした階段状になってしまうため適度に中間色を加えぼかしをうまく利用する必要があります。

にじみ状態パターン②色が飛び出る

　上記で修正したテクスチャを取り込んでみます。すると中央の黄色とピンクが接触している部分で黄色がピンクの中に飛び出ています。
しかしテクスチャをみてもそれらしい色はみあたりません。
ここが難しいところで、Unity上で拡大した際、ゲーム画面上でもなめらかに表示されるよう更に画面表示処理がかかります。そのため少しの色味でも影響範囲が大きく、上記のように隣り合った色の範囲がお互いに狭いと色が侵食することがあります。
この場合はテクスチャの侵食している部分、とその付近をそれぞれ同系統の色で塗りつぶす必要があります。

例えば黄色が侵食しているのならば侵食範囲に濃い目のピンクを、接触している部分に中間色を。そのように修正データを作成しては組み込み、侵食がどの程度消えるかを繰り返し確認していきます。1ピクセル・僅かな色の違いで影響範囲が大きいため都度確認し地道に潰していきます。

にじみ状態パターン③使用していない色がにじみ出る

　①②で使用している画像にもうっすら出ていますが、青なのになぜか赤色が滲み出ていたり、明るい色なのになぜか端に黒い色が表示されるという問題も出ることがあります。
　前者は色の境界部分で発生することが多いです。こちらは少し離れた色が影響してる、
もしくは「隣の色か滲みが発生している面の色を構成している色（青色でもわずかに赤と白がまじった色みなど）」が影響している場合があります。
そのため、発生している場所にわざと同系色の濃い色をおいたり、青に赤がでるならば多少青寄りの色を境界におくことで影響を軽減させられる場合があります。
　後者は使用している色のうち同色だと思っていた部分にほんの僅かなに色味の異なる色がのっていた場合などに起こります。
そのため、同色で異なる色が出る部分をマスクをかけて塗りつぶしてみたりすると問題が解消されます。

にじみ状態パターン④線から隣の色がはみ出て表示される

　①のように中間色の線も潰し、③のように同色で塗りつぶしたとしても場合によっては中には図のように間の線をこして隣の色に広範囲に侵食する場合があります。
こちらの対処法は２点。
一つは、間の線を面にすること。間の色の範囲を大きくすることで侵食を消すことができます。
間の色に侵食するだけじゃないの？とも思いますが案外大きくした間の色には同じような色の侵食は発生しません。
もう一つは、色の系統を統一させてしまうこと。青をメインに使いたいならば寒色系と色を統一など、系統を統一させることで④のような侵食を防ぐことができます。

　どちらもデザインを変える最終手段ではありますが、イラストを作成中に事前に組み込んで問題ないかを確認していけば早い段階で手が打てますね。

最後に

拡大縮小せずデータを使用せれば一番問題ないのですが、画像データもなかなか重く、大きいデータを使用すれば使用するほどゲーム全体の容量も圧迫してしまいます。抑えられるものは抑えて、Unity上の設定で補えるものは補って動作の軽い快適なゲームを作成していきましょう。

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

やりたいこと
「条件A」なら、A.html、「条件B」なら、B.html
のように、クリックした要素に応じた外部htmlを読み込み、
閉じるをクリックしたら外部html部分は削除したい。
読み込んだり削除したりを繰り返したい。
呼び出し元・外部htmlどちらでもjsが必要だけど、
jsファイルがすでにたくさんあるので1つにまとめたい。

$.ajaxで外部htmlを読み込む

まず、htmlでトリガーになる部分を作ります。

<a href="modal_A.html" class="js-modal_trigger">Aを選択</a>
<a href="modal_B.html" class="js-modal_trigger">Bを選択</a>

今回は読み込んだ後も別の外部htmlを読み込み直したりしたいので、
$.ajaxを使うことにします。

$(".js-modal_trigger").click(function(e) {
  e.preventDefault();
  //読み込みたい外部htmlのファイル名を取得
  var href = $(this).attr("href"); 

  //読み込んだファイルを展開するdivを作る
  $(this).after("<div class=\"js-modal\"></div>"); 

  $.ajax({
    type: 'GET',
    url: href,
    dataType: 'html',
    success: function(data) {
      //取得したhtmlを作成したdivに追加
      $(".js-modal").append(data);
    },
    error: function() {
      alert('問題がありました。');
    }
  });
});

読み込みたいhtmlが1種類ではないので、urlに入れる値はaタグのhrefから取得しています。
あと、読み込んだhtmlの展開用の空divが最初からhtml上にあるのも気持ち悪いので、
クリックのタイミングで毎回作ることにしました。

.remove()で要素を削除する

読み込みができたので、今度は閉じるをクリックしたら外部html部分を削除する部分を作ります。

<div class="js-modal_close">閉じる</div>

htmlを用意して、読み込まれた部分を削除するjsを追加。

$(".js-modal_close").click(function() {
  $(".js-modal").remove();
});

.js-modal_closeが読み込んだ外部htmlの中にある場合、
呼び出し元のページで上記のjsを読み込んでいても、このままでは動きません。
なので、これをfunctionにします。

function modalClose() {
  $(".js-modal_close").click(function() {
    $(".js-modal").remove();
  });
});

このfunctionを外部htmlを読み込んだ後に実行します。

$(".js-modal_trigger").click(function(e) {
  e.preventDefault();
  //読み込みたい外部htmlのファイル名を取得
  var href = $(this).attr("href"); 

  //読み込んだファイルを展開するdivを作る
  $(this).after("<div class=\"js-modal\"></div>"); 

  $.ajax({
    type: 'GET',
    url: href,
    dataType: 'html',
    success: function(data) {
      //取得したhtmlを作成したdivに追加
      $(".js-modal").append(data);
      modalClose(); //閉じる
    },
    error: function() {
      alert('問題がありました。');
    }
  });
});

閉じる以外にも、外部htmlでjsを実行したい場合は、
同じように関数にして読み込むと良さそうです。

番外：どんどん増殖する外部html

最初、何も考えずに外部htmlの中でjsファイルを読みこませて動かしてみたところ、
1回目のクリック…読み込み、削除問題なし。
2回目のクリック…外部htmlの要素が2回読み込まれる。
3回目のクリック…外部htmlの要素が4回読み込まれる。

明らかにおかしい。
クリックのイベントがいけないのかと思い、
試しにページロード時に外部htmlを読むようにしてみようと
ちょっと書き換えました。

$(".js-modal_trigger").each(function(e) {
  e.preventDefault();
  //読み込みたい外部htmlのファイル名を取得
  var href = $(this).attr("href"); 

  //読み込んだファイルを展開するdivを作る
  $(this).after("<div class=\"js-modal\"></div>"); 

  $.ajax({
    type: 'GET',
    url: href,
    dataType: 'html',
    success: function(data) {
      //取得したhtmlを作成したdivに追加
      $(".js-modal").append(data);
    },
    error: function() {
      alert('問題がありました。');
    }
  });
});

その結果、<div class=”js-modal”></div>を生成し、外部htmlを取り込む処理を
ひたすらループし続ける悲劇が…
止まらないのでブラウザを強制終了。
ちなみに、.load()でも同じように無限ループが発生しました。
面倒なんて言わずに、最初からおとなしくfunctionにしておけばよかったのです…

教訓
同じjsファイルを再読み込みするのは良くない。

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

3月6日にデータポータルの計算フィールドUIが変更されました。行を分けて記述できるようになったことで、従来の計算フィールドよりも書きやすく、理解しやすい構造になっています。今回は新しい計算フィールドUIをご紹介します。

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

こんにちは。株式会社アピリッツでアナリストをしているssekiです。
今回は、計算フィールドのUI変更についてご紹介いたします。

計算フィールドとは、デフォルトの指標やディメンションを組み合わせて作成するフィールドのことです。
Googleデータポータルの計算自由度を高める機能である反面、UIが見づらいために非プログラマーはもちろん、プログラマーにとってもとっつきにくいと感じる部分でしょう。
（実際、自分は今までメモ帳に一度記述してから、コピペしてました。）

今回のUI変更によってプログラマーが設計しやすく変貌いたしましたのでご紹介いたします！！

今までの計算フィールドUI

過去の計算フィールドはプログラマー泣かせなUIでした。
なんといっても、「コードをすべて一行で書きなさい」と言わんばかりの入力部分。
（実際、複数行に分けて書いたコードをコピペするとエラーが起きてたので、一行で書かなければならなかったのでしょう。）
正直、非プログラマーの私から見てもナンセンスだなと感じていました。
過去に書いたCASE関数の記事でもすべて一行で書いてますね。これではエラーが続出するのも仕方ありません。

CASE WHEN 第 1 階層 = "/a/" THEN "A" WHEN 第 1 階層 = "/b/" THEN "B" WHEN 第 1 階層 = "/c/" THEN "C" WHEN 第 1 階層 = "/d/" THEN "D" WHEN 第 1 階層 = "/e/" THEN "E" END

例えば上のような計算フィールドを「全アルファベットで」、なんて言われたら気が遠くなりますね・・・。
しかも、書いてくうちにページが重くなっていく・・・。（なのでメモ帳を使っていました）

新しい計算フィールドUI

新しくなった計算フィールドはそんな鬼畜なことを言いません！
まずは実物を見てみてください。↓


「うわ・・・私の計算フィールド、広すぎっ・・・！」

ってなりますよね。私もなりました。
しかも、便利機能満載なんです。とりあえず３つ挙げておきます。

1. 数式を複数行で作成可能
2. 左側メニューから数式に含める項目を選択可能
3. 数式が長くなっても重くならない（気がする）

便利機能1：数式を複数行で作成可能

これすごい便利ですよね。何が便利かって、作成途中のエラーに気づきやすいところがすごい。
あとは、他の人が計算フィールド見た時にどんな数式になっているか一目でわかるところが神です。
先ほどの「アルファベット」のコード、このUIなら僕はこう書きます。

あぁ、勢い余ってj行まで書いてしまいました。
インデントのためにスペースやタブを使っても数式エラーにならないところが最高ですね。

便利機能2：左側メニューから数式に含める項目を選択可能

今までのUIからは考えられないほど、スムーズに数式に含める変数を選択できます。
以前も検索可能でしたが、検索するたびに落ちそうになるほど重かったのを覚えています。
しかも、GAの指標って変なところにスペース入っていたりして検索しづらいんですよね・・・。
地味に便利な機能だと思います。

便利機能3：数式が長くなっても重くならない（気がする）

数式が長くなっても重くなりません！！
試しに1000行くらいまで先ほどの計算フィールドを延長してみましたが、問題なく動いていました。
（以前だったら問答無用で落ちていたでしょう・・・。）
これでどんなに長い計算フィールドを要求されても、記述することができますね（遠い目）。

まとめ：新しいUIの計算フィールドは便利

簡単にまとめると、新UIになったことで各段に便利になりました。
しかし、これまでの記事（私の記事を含む、世界中の数多あるデータポータルの記事）では、まだ新UI用のテンプレコードに対応されていないのも現状・・・。
コピペではなく、本当の意味で計算フィールドの関数を理解する必要がありそうですね！

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

3月6日にデータポータルの計算フィールドUIが変更されました。行を分けて記述できるようになったことで、従来の計算フィールドよりも書きやすく、理解しやすい構造になっています。今回は新しい計算フィールドUIをご紹介します。

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

こんにちは。株式会社アピリッツでアナリストをしているssekiです。
今回は、計算フィールドのUI変更についてご紹介いたします。

計算フィールドとは、デフォルトの指標やディメンションを組み合わせて作成するフィールドのことです。
Googleデータポータルの計算自由度を高める機能である反面、UIが見づらいために非プログラマーはもちろん、プログラマーにとってもとっつきにくいと感じる部分でしょう。
（実際、自分は今までメモ帳に一度記述してから、コピペしてました。）

今回のUI変更によってプログラマーが設計しやすく変貌いたしましたのでご紹介いたします！！

今までの計算フィールドUI

過去の計算フィールドはプログラマー泣かせなUIでした。
なんといっても、「コードをすべて一行で書きなさい」と言わんばかりの入力部分。
（実際、複数行に分けて書いたコードをコピペするとエラーが起きてたので、一行で書かなければならなかったのでしょう。）
正直、非プログラマーの私から見てもナンセンスだなと感じていました。
過去に書いたCASE関数の記事でもすべて一行で書いてますね。これではエラーが続出するのも仕方ありません。

CASE WHEN 第 1 階層 = "/a/" THEN "A" WHEN 第 1 階層 = "/b/" THEN "B" WHEN 第 1 階層 = "/c/" THEN "C" WHEN 第 1 階層 = "/d/" THEN "D" WHEN 第 1 階層 = "/e/" THEN "E" END

例えば上のような計算フィールドを「全アルファベットで」、なんて言われたら気が遠くなりますね・・・。
しかも、書いてくうちにページが重くなっていく・・・。（なのでメモ帳を使っていました）

新しい計算フィールドUI

新しくなった計算フィールドはそんな鬼畜なことを言いません！
まずは実物を見てみてください。↓


「うわ・・・私の計算フィールド、広すぎっ・・・！」

ってなりますよね。私もなりました。
しかも、便利機能満載なんです。とりあえず３つ挙げておきます。

1. 数式を複数行で作成可能
2. 左側メニューから数式に含める項目を選択可能
3. 数式が長くなっても重くならない（気がする）

便利機能1：数式を複数行で作成可能

これすごい便利ですよね。何が便利かって、作成途中のエラーに気づきやすいところがすごい。
あとは、他の人が計算フィールド見た時にどんな数式になっているか一目でわかるところが神です。
先ほどの「アルファベット」のコード、このUIなら僕はこう書きます。

あぁ、勢い余ってj行まで書いてしまいました。
インデントのためにスペースやタブを使っても数式エラーにならないところが最高ですね。

便利機能2：左側メニューから数式に含める項目を選択可能

今までのUIからは考えられないほど、スムーズに数式に含める変数を選択できます。
以前も検索可能でしたが、検索するたびに落ちそうになるほど重かったのを覚えています。
しかも、GAの指標って変なところにスペース入っていたりして検索しづらいんですよね・・・。
地味に便利な機能だと思います。

便利機能3：数式が長くなっても重くならない（気がする）

数式が長くなっても重くなりません！！
試しに1000行くらいまで先ほどの計算フィールドを延長してみましたが、問題なく動いていました。
（以前だったら問答無用で落ちていたでしょう・・・。）
これでどんなに長い計算フィールドを要求されても、記述することができますね（遠い目）。

まとめ：新しいUIの計算フィールドは便利

簡単にまとめると、新UIになったことで各段に便利になりました。
しかし、これまでの記事（私の記事を含む、世界中の数多あるデータポータルの記事）では、まだ新UI用のテンプレコードに対応されていないのも現状・・・。
コピペではなく、本当の意味で計算フィールドの関数を理解する必要がありそうですね！

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

私は始め、CUIでGitを使っていましたが、”Sourcetree”を上司からおすすめされたので使ってみました。 その簡単な説明を行っていきます。

CUIとGUI

CUIとGUIの違いについてざっくりと説明しますと、
・CUIとは”Character User Interface”の略で、Windowsで言うところの『コマンドプロンプト』、Macで言うところの『ターミナル』のような、情報の表示を文字のみで行い、キーボードを使用してPCを操作する画面のことである。

・GUIとは”Graphical User Interface”の略で、アイコンやボタンを表示してマウスでクリックすることでPCを操作する画面のことを言う。
といったところです。

GUIで扱うGit

実際に画面を見てみましょう。

※画像には一部修正を加えています。

画面中央、最も大きな領域にはコミットログなどが表示されます。

ブランチの分岐などが視覚的にわかるようになっています。

画面下部の領域には変更されたファイルやその差分が表示されます。

コミットメッセージや作業者の名前も表示されるので、『誰がどのような変更を行ったか』が一目で分かります。

画面上部にはコミット、プル、プッシュといったボタンが並んでいます。

スタッシュした変更は画面左側、『一時退避』に表示されます。スタッシュした変更は右クリックからいつでも戻すことが出来ます。

おわりに

Sourcetreeは、すでにCUIでGitを利用しているがどうしても操作に慣れない非エンジニアの方だけでなく、Gitを使い始めた初心者のかたにもおすすめできます。

エンジニアの方からするとCUIのほうが楽だという意見もあります。

Sourcetreeに慣れた人も、CUIでGitを使ってみると勉強になることがあるかもしれません。

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

Unityの画像の端に謎の線・点が出たこと、ありませんか？直したいですね。

こんにちは。最近はずっとuGUIでUIをいじっています。

この記事画像に並んでいるのは弊社ゲームシリーズ「式姫Project」の 狛犬 です。
この子に例になってもらい、下の画像のような謎の線について、どうしてこれが起こるのか・どうすればこれが起こらないのかについて書きたいと思います。

どうして線が見えるのか

この線が一体どこから出てきたものかというと、画像の逆の端の色からきたものです。
少し間をあけて並べてみるとわかりやすいですね。

どうしてそんなところの色が混ざってしまうのか、テクスチャのインポート設定(の一部)を見ていきたいと思います。
今の Texture Import Settings はこんな感じです。

ここで見るべき設定は

• Wrap Mode
• (Filter Mode)

です。

結論から言うと

Wrap Mode が Repeat になっていたら Clamp にしましょう。

Wrap Mode

画像を伸ばすときにどうやって伸ばすか？というのが Wrap Mode です。

• Repeat
• Clamp

Repeatは同じ画像を並べて使うときなど、端の隣を逆の端とする設定です。
Clampは画像を並べず単体で使うときなど、端の隣は端をそのままのばしたものになる設定です。

ここが Repeat になっていると逆側の端を見てしまい謎の線が出るわけです。

続きはそもそもなぜ逆の端を参照する必要があるのか？という話です。

Filter Mode

画像の1ピクセルがそのまま画面の1ピクセルになるわけではありません。
では画面の1ピクセルの色をどうやって決めるのか？というのが Filter Mode です。

• point
• bilinear
• trilinear

Filter Mode には上の3種類があります。

Point は、近い1点のみをみてその色をとってきます。
たとえばドット絵をぼやかさずにドットらしく見せたいときははこの設定を使います。

Biliner は近い点の平均の色をとります。
極端な拡大縮小でなければうまくぼかして見えるので、UIを作っている中ではたいていBilinerを使っています。

Triliner は Biliner と似たようなものですが、これはミップマップを参照します。
他の方の記事にありますが、2Dではあまりカメラとの距離が変わらないので使うことはありません。

PointとBilinearの画像を見比べてみると、どういったときにどちらを使うかわかりやすいですね。

ここまででわかったかと思いますが、逆の端の色が混ざるのは

• Filter Mode が Bilinerなので近くの色を平均して色を決めている
• Wrap Mode が Repeatなので近くの色に逆の端の色が入る

からですね。Wrap Mode を Clamp にしましょう。

きれいになりました。

この設定、特に動的にTexture2Dを生成したときに忘れがちです。
スクリプトからもWrapModeは変更できるので忘れずに設定しておきましょう。

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

以前rubyの大域脱出を紹介した際にrubyには継続渡しがあると話をしたので、簡単に解説してみた上で継続渡しとFiberの理解のためcallccを使ったEvilFiberを実装してみました。

はじめに

17新卒エンジニアくろすです。
使ってたBluetoothイヤホンが断線したり、代わりに通販で買ったイヤホンが初期不良で電源入らなかったりと本厄の洗礼が激しく、お祓いに行こうか真剣に悩んでます。
誰かオススメの厄払いがある方いらっしゃいましたら連絡をください。

今回は楽しい黒魔術の話だけ書いてパパッと終わらせちゃうぞ、と思っていました。
思っていました。
callccからFiberの話なんか始めちゃったのが間違いでした。

環境等

環境 : ruby-2.4.2
callccを使おうとcontinuationをrequireすると

warning: callcc is obsolete; use Fiber instead

と怒られます。

処理の中断、再開として使うなら Fiber
大域脱出として使うなら throw..catch
があるのでそちらを使いましょう。

黄泉還りを楽しみたい方は遊びの範囲内で使いましょう。

黒魔術

メタプログラミングによる動的なコード生成や加工が黒魔術と呼ばれることが多いです。
Rubyで有名なのは
与えられた文字列をrubyのコードとして解釈するようなeval属
動的なメソッドを生成、またはそのメソッドが存在するかのように見せかけるdefine_methodやmethod_missingによるゴーストメソッド
などがあります。
今回はRuby黒魔術の中でも黄泉還りが危険すぎてrequireしないと使えないようになってしまっているcallccについて軽く触れていきたいと思います。

Rubyの継続

require 'continuation'

x = 1
if x == 1
  y = x * callcc{|cont| @a = cont; x}
  puts y
end
if y < 5
  x += 1
  @a.call(x)
end

callccを呼ぶことでcallcc以降のコンテキスト(継続)を@aに保存して、@a.call(x)でcallcc{|cont| @a = cont; x}の返り値に、call時のxの値を代入して5行目に戻ります。
パッと見、yにはx² が入りそうな感じがしますが、Ruby的には最初に5行目を評価した時点で、xの値も評価し終わっているようで結果は以下のようになります。

$ ruby black_magic.rb
1
2
3
4
5

一歩間違えば無限ループ入りまっしぐらなのが見てわかるかと。

ちなみに、5行目を以下のように変更すると

y = callcc{|cont| @a = cont; x} * x

結果はこうなります。

$ ruby black_magic.rb
1
4
9

ざっくり継続の感じが掴めましたでしょうか。

Fiber

話が少し飛びますが、そもそもFiberとはなんぞ？という疑問がありそうなので軽く引用します。

ノンプリエンプティブな軽量スレッド(以下ファイバーと呼ぶ)を提供します。 他の言語では coroutine あるいは semicoroutine と呼ばれることもあります。 Thread と違いユーザレベルスレッドとして実装されています。

引用 : Ruby2.5.0 Fiberクラスリファレンス

Rubyはそもそもの言語仕様として同時に実行されるネイティブスレッドは常にひとつだったりするんで、あくまでRubyVM内でノンプリエンプティブだって話ですが……
参考 : Ruby2.5.0 Threadクラスリファレンス

もう完全にコルーチンなんですが、要するにrubyのコードレベルで明示的にコンテキストを変更できる軽量なスレッド(スレッドではない)です。
Ruby的にわかりやすく言うならば処理の中断再開が可能なProcオブジェクト的な感じです。
以下のようにfiber自体は同一スレッド内でコンテキストを変更して動きますし、別スレッドからresumeしようとするとFiberErrorって怒られます。

require 'fiber'

fiber =
  Fiber.new do
    loop do
      Fiber.yield Thread.current.object_id
    end
  end

puts <<-EOS
===========================
  parent : #{Thread.current.object_id}
  child  : #{fiber.resume}
===========================
EOS
#=>
# ===========================
#   parent : 70103219828660
#   child  : 70103219828660
# ===========================

EvilFiber

callccを使い実装した邪悪なFiberです。
このブログのcounterを参考にさらに抽象度を上げてFiberに近づけた形になります。
元記事でも言われてますが、stopとresumeのスパゲッティ具合がとにかく邪悪です。
限界までFiberとfiber(コルーチンライクに使うための標準ライブラリ)に合わせようと思いましたが、#transferとスレッドセーフを実装する気力はなかったです……

require 'continuation'

class EvilFiber
  @@fibers_hash = {}
  @@current = nil
  @@prev = nil

  class << self
    def yield(*args)
      @@current.stop(*args)
    end

    def current
      @@current
    end

    def prev
      @@prev
    end

    private
    def fibers_hash
      @@fibers_hash
    end
  end

  def initialize
    @@fibers_hash[self.object_id] = self
    @resume =
      proc do
        yield
        @dead = true
        reset_registered_fiber
        nil
      end
  end

  def stop(*args)
    reset_registered_fiber
    callcc do |cont|
      @resume = cont
      @return.call(*args)
    end
  end

  def resume
    raise 'THIS FIBER DIED!!!' if self.dead?
    @@current = @@fibers_hash[self.object_id]
    callcc do |ret|
      @return = ret
      @resume.call
    end
  end

  def alive?
    not @dead
  end

  def dead?
    !!@dead
  end

  private
  def reset_registered_fiber
    @@prev, @@current = @@current, nil
  end

end

[1] pry(main)> require_relative 'evil_fiber'
warning: callcc is obsolete; use Fiber instead
=> true
[2] pry(main)> f = EvilFiber.new{ puts '小烏丸'; EvilFiber.yield; puts '蜥蜴丸'; EvilFiber.yield; puts '小狐丸' }
=> #<EvilFiber:0x00007fc61a0e7dc8 @resume=#<Proc:0x00007fc61a0e7d50>>
[3] pry(main)> f.resume
小烏丸
[4] pry(main)> f.resume
蜥蜴丸
[5] pry(main)> f.resume
小狐丸
[6] pry(main)> f.resume
RuntimeError: THIS FIBER DIED!!!

new時に渡しているブロック内のEvilFiber.yieldをf.yieldにするという実装もあったのですが、コードとして見たときにパッと見未生成に見えるオブジェクトを触っているのが気持ち悪いので、Fiber側に合わせる方向にしました。
実際渡してるブロックが評価されるのはブロックがcallされた時(つまりこのコードだと最初にresumeが呼ばれた時)で、mainのオブジェクトのBindingから変数fを引っ張ってくるはずなので動くと思うんですが気持ち悪いものは気持ち悪いです。
オブジェクトの生成とブロックの登録を分ければ多少気持ち悪さが解消される気がします。

終わりに

ざっくりとですが、callccとFiberの勉強ができていい機会になったなって思います。
特にFiberですが、Threadよりコードに寄ってくれるので個人的にはかなり楽に書けるなと印象でした。
マルチスレッドプログラミングじゃなくてただのコルーチンと化した使い方しかしていないのでそりゃそうですけど。
一度ちゃんとマルチスレッドプログラミング勉強しないとなぁ……

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

メールソフトは多々ありますが、私はThunderbirdを使用しています。

強力なフィルタ機能

メールは日夜多方面から飛んできます。

それをひとつひとつ手作業でフォルダ分けするのは手間ですし、時間がもったいないです。

Thunderbirdには強力なメールフィルタ機能があります。下の図1、図2をご覧ください。

[図1]

[図2]

ここでは、メールをフィルタリングする条件を決めることができます。

また、複数の条件を組み合わせることもできるため、フィルタリングしたメールから特定のメールを探したい場合に便利です。

メールテンプレートを作ることができる

お問い合わせ対応などで同じ形式のメールを送る必要がある場合、

過去に送信したメールからコピペしてきて再利用……とするのではなく、

メールテンプレート機能を利用しましょう。

作成したメールをテンプレートとして保存する機能がThunderbirdには備わっています。

作成したテンプレートは専用フォルダに振り分けられ、右クリックから[新しいメッセージとして編集]を選ぶことで使用できます。

おわりに

仕事でメールチェックをしていると、迷惑メールが大量に送られてくる場合があります。

本当に大切なメールやお問い合わせが埋もれてしまうのを避けるため、

私はThunderbirdを使用して迷惑メールはそれ専用のフォルダに入るよう設定しています。

みなさんもThunderbirdで快適なメール生活を送りましょう。

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

メモソフトは数えきれないほどたくさんありますが、逆にたくさんありすぎて何を使えばいいか分からない！と悩むことが多いです。
そこで、私が最近使用した中で使い勝手の良かったもの2つを紹介していきたいと思います。

CubeNote

CubeNote

PC用フリーソフトです。

利点
自動保存
タイトルを付ける手間が不要
メモの管理がとても楽

不満点
特になし

使用した感想
メモにタイトルを付けて保存するという作業を必要としないのが特徴です。
メモ編集欄の横にメモの一覧が表示されるため、そこから編集したいメモを選択、または新しいメモを追加して編集を行うことが出来ます。
もちろん、メモの一覧は非表示にすることも可能です。
メモの並び替えもでき、普段使用しないものは下の方に置いておくことで、一覧をスクロールする手間も少なくなります。

非常にシンプルなインターフェースですが、行数や文字数の表示などは揃っています。
また、メモ一つ一つにタグを設定できるため、探しているメモをすぐに見つけることが出来ます。

二か月ほど使用していますが、動作が非常に軽く、インターフェースもスッキリしていて美しく、今のところ不満点はありません。

CosMoNOTE

CosMoNOTE

ブラウザ上で動くメモサイトです。（アカウント登録が必要になります)

利点
自動保存
ブラウザで動くのでどこでも編集可能
Markdownが使用可能
タブインデントができる

不満点
自由にメモの並び替えができない

使用した感想
いつでもどこでも気軽に編集できるのが強みです。

上で紹介したCubeNoteと似ていて、左の欄にメモの一覧が表示されるため、管理がとても楽です。
こちらはタイトルとメモ本文が別々になっていますが、同じ画面で編集できるため手間もありません。

また、CosMoNOTEはMarkdown記法を使用できるため、自分好みにメモを見やすくすることも可能です。
Markdown記法については、以前くじらさんが記事を書いています。
Markdownとはなんぞや……という方は、そちらもご覧になってみてください。
Markdownのすすめ　←記事はコチラ

このサイトでは、更新日時順に上から自動的にメモが並び替えられていくので、よく使用するメモを見失うことがありません。
……が、メモを自分の思い通りの順番にしておきたい場合は、管理が少し面倒になってしまうかもしれません。
この並び替え機能は、アップデートで対応を検討しているようなので、これが出来るようになれば個人的な不満点は解消されます！

なんといっても、ブラウザで動くのが利点です。
パソコンでもスマートフォンでも、インストールする必要がなくサッとメモを取ることが出来ます。
動作が軽く、機能も非常にシンプルなため無駄が少ないです。

ただ、あくまでもネット上のサービスであるため、パスワード等は記載しないようにするなど、セキュリティやプライバシーに注意して使用しましょう。

[PHP+JS]マークダウン形式のシンプルなメモ帳サイトを作ってみた！
開発者の方の記事はコチラ。

まとめ

忘れっぽいので、自動保存してくれるツールでないと大変な目に合うことがしばしば……
なので、自動保存できるかどうかを重視しています。

ツールが変わればやる気も変わります。
自分に合ったメモソフト・メモサイトを見つけて、ストレスフリーなメモ生活を送りましょう！

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

以前、メカニカルキーボードをおすすめする記事を書きましたが、 今回はメカニカルキーボードを使う際の注意点を書いていきます。

以前の記事はこちらです。

チルトスタンドは使わない

メカニカルキーボードだけに限ったことではありませんが、

チルトスタンドがあるキーボードに関しては、これを使わないことを推奨します。

チルトスタンドとはキーボードの裏についている足のことで、これを立てることで手首を上に曲げた状態でタイピングをすることになるため、負担がかかってしまいます。

少しでも手首への負担を減らしたい、という方はチルトスタンドを使わないほうがいいでしょう。

また、メカニカルキーボードの場合、大抵の機種は厚みがあるため、チルトスタンドを使わなくても手首が曲がった状態でタイピングをすることになります。
チルトスタンドを使うと更に傾斜するため、より手首に負担がかかってしまいます。

それを解消するための方法が、以下の方法です。

パームレストを使う

パームレストとはキーボードの手前に置くクッションのことで、手のひらを乗せてタイピングすることで手首への負担を軽減することができます。

シリコン素材や柔らかい素材のものが多く市販されていますが、私は木でできたパームレストを推奨します。

なぜならば、柔らかい素材だと手首が沈み込んでしまい、結局手首へ負担がかかってしまうからです。

キーを打つ手がデスクに対して並行を保ち、負担を最小限にするには、固い素材のものが推奨されます。

おわりに

日々PCを使って仕事を行う社会人にとって、手首は守るべき大切なものです。

手首を痛めて仕事が出来ないということが無いよう、大切にしましょう。

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

どうも僕です。 タイトルの「ギスらない」というのは、「ギスギスしない」ということです。 そしてそれはつまり、「人間関係の不調和を起こさない」ということです。

相手が言っていることを理解する

オンラインゲームにおいて、画面の向こうには生身の人間がいます。

中には文章で自分の意見や思いを伝えるのが苦手な人もいるでしょう。

そのような時に大切なことは、相手の考えと自分の理解が合致しているかどうかを確かめることです。

そのためには、「相手の考えを理解し、自分の言葉で説明する」ということが必要です。

このときに気を付けたいのは、わかりやすい平易な言葉を使うことです。辞書に載っていないような独自の言葉や身内でしか通じないような略語、わかりにくい表現は避けるべきです。

自分の考えを伝える

自分から相手に考えを説明するときに大切なことは、「高圧的な態度にならない」ということです。

例えば、明らかにおかしな動きをしているプレイヤーがいたとしましょう。

その人に対してどう接するかは個々人の自由ですが、画面の向こう側にいる人は生身の人間であるということを思い浮かべましょう。まずは相手の事情を尋ねるべきです。

もしかしたら初心者なのかもしれませんし、不慣れなだけかもしれません。そういうプレイヤーに対しては優しくアドバイスをしてあげましょう。

中には他人に迷惑をかける目的のプレイヤーもいるかもしれません。そういった人に対しては毅然とした態度かつ暴言にならないよう、関わりを断つべきです。

おわりに

このことはオンラインゲームだけでなく、文字でやりとりを行うツールすべてに当てはまると考えています。

文章からは口調や表情を読み取ることはできません。それゆえに相手の考えを理解すること、自分の考えを伝えることが大事になります。

この記事はアピリッツの技術ブログ「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メートル飛ばしているような図式になってしまいましたが、それでも相当の速度が求められますね。