ホーム ブログ ページ 21

有料Asset「RateBox」の使い方

0

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

アプリレビュー機能を実装する際に使ったAssetについて使い方を備忘録的にまとめます。

はじめに

皆さんはスマートフォン向けアプリを探しているとき、どこに目が行くでしょうか?
私はまずアイコンを見て、タイトルを見て、それから星の数を見ます。
または、アイコンやタイトルに惹かれて詳細画面に進んだ後に、星の数をチェックします。

皆さんご存知の通り、星の数はアプリに対する評価の高さを意味します。
もちろん、AppStore・GooglePlayStore共に、ユーザーが自由にレビュー出来るシステムなので、不当な評価をされている可能性も無くはないのですが、それでも星の数はおおよそアプリの評価を表します。

評価の低いアプリをわざわざインストールしたいと思うユーザーはいないでしょうし、似たような機能のアプリがあれば評価の高い方を選びたくなるのがユーザー心理だと思います。

今回は、そんなアプリの評価を高めるため、ユーザーに対してレビューを依頼する機能をUnityの有料Assetを用いて実装する方法をご紹介します。

アプリレビュー機能を実装するためのAsset

https://assetstore.unity.com/packages/tools/integration/ratebox-ios-android-rate-review-popup-75190

今回ご紹介するAssetは、こちらの「RateBox」です。
2018年3月末現在の価格は$12.95、だいたい1400円ぐらいです。
Unityのバージョン5.0.0以降に対応しています。

このRateBoxは、iOSのバージョン10.3.3以上のiOS内蔵のレビュー機能に対応しています。

iOS10.3.3以上内蔵ウィンドウについて

RateBoxの話を進める前に、アプリのレビュー機能に関して気をつけなければならないことがあるのでお話しておきます。
iOSのバージョンが10.3.3以上の場合、AppleはiOSのSDKが提供するレビュー依頼用のウィンドウを表示することを義務付けています。
このウィンドウは、アプリから離れることなくウィンドウ上で星の数を選んでレビューを行うことが出来るもので、ユーザー的にも煩わしい遷移を行うことなく手軽にアプリの評価が行えるものになっています。
iOS10.3.3に対応するアプリなのに、このiOS内蔵のレビューウィンドウを使用しない場合、審査のリジェクト対象となる可能性があるため、RateBoxに備わっている機能を用いて対応することが望ましいでしょう。

RateBoxの使い方

無事Assetを購入し終えたら、Unityにインポートしましょう。
デフォルトではデモシーンやそれに伴うプレハブが付属してきますが、デモシーンを活用せずともドキュメントを読むことで大雑把な使い方は理解できるため、アプリ容量等を気にしている場合はインポートしなくても問題ありません。

以下、そのドキュメントや実装の経験談をもとに、簡単に使い方をまとめていこうと思います。
※今回は、アプリのレビュー誘導のためにオリジナルのウィンドウを表示させたいケースを想定して説明していきます

  1. 自作ウィンドウクラスの作成
    あなたの好きなデザインのウィンドウを作成しましょう。
    ウィンドウのプレハブを作成し、スクリプトをアタッチします。
    スクリプトには必ず IAlertPlatformAdapter インターフェースを継承させ、各種メソッドをオーバーライドする必要があります。
    重要なのは IAlertPlatformAdapter.Show と IAlertPlatformAdapter.Dismiss で、前者はウィンドウを表示する時に呼ばれる関数、後者はウィンドウを閉じる時に呼ばれる関数です。ウィンドウを表示したり消したりする処理はここで行うといいでしょう。
    もちろん、ウィンドウに設置した「レビューする」「後回し」「二度としない」などの各種ボタンを押したときのコールバックも記述してボタンにアタッチしましょう。
  2. 初期化
    RateBox.Instance.Init を、レビュー依頼を出したい画面より前に実行します。(アプリの起動時に行うのが良さそう)
    第一引数にはレビューボタンを押したときに遷移させるURLを指定します。プラットフォームがiOSならAppStoreのレビューページ、AndroidならGooglePlayStoreのレビューページを指定します。
    その他、第二引数以降は任意で以下のパラメータを渡します。
    • 第二引数: RateBoxConditions クラスのインスタンス
    • 第三引数: RateBoxTextSettings クラスのインスタンス
    • 第四引数: RateBoxSettings クラスのインスタンス

これらのクラスに関しては、次の項目で詳しく説明します。

  1. RateBoxの設定 RateBoxには、レビュー依頼ウィンドウを表示する際の条件などの設定を行うためのクラス RateBoxConditions 、RateBoxTextSettings 、 RateBoxSettings が存在します。

  • RateBoxConditions クラスはレビュー依頼ウィンドウを出す条件に関するプロパティを持ち、それぞれの設定項目は以下の通りです。
    • MinSessionCount RateBox.Instance.Initの呼ばれた回数が MinSessionCount 以上のときにレビュー依頼が表示されるようになります。
    • MinCustomEventsCount カスタムイベント(任意の条件)のカウンターの数が MinCustomEventsCount 以上のときにレビュー依頼が表示されるようになります。カウンターは RateBox.Instance.IncrementCustomCounter() で増やすことが出来ます。(例:ミニゲームを1回クリアするごとにカウンターを1増やし、5回クリアした時点で表示する)
    • DelayAfterInstallInSeconds インストールされてからの秒数が DelayAfterInstallInSeconds に指定した秒数以上のときに表示されるようになります。
    • DelayAfterLaunchInSeconds アプリを起動してからの秒数が DelayAfterLaunchInSeconds に指定した秒数以上のときに表示されるようになります。
    • PostponeCooldownInSeconds 一度レビュー依頼ウィンドウが表示されてから、次に表示可能になるまでの秒数です。デフォルトでは22時間(=79200秒)になっています。
    • RequireInternetConnection trueのとき、インターネット接続がされている状態でのみ表示します。

  • RateBoxTextSettings クラスは以下のプロパティを持ちます。それぞれ意味はプロパティ名そのままで、渡した値がRateBox備え付けのUIに反映されます。
    • Title
    • Message
    • RateButtonTitle
    • PostponeButtonTitle
    • RejectButtonTitle

ただし、 RejectButtonTitle だけは重要で、これが空だと「二度と表示しない」ボタンを押した時のコールバックが機能しなくなってしまいます。自作ウィンドウで「二度と表示しない」ボタンを表示したい場合は、適当な文字列を渡すといいでしょう。


  • RateBoxSettings クラスは、 UseIOSReview プロパティを持ちます。これがtrueのとき、RateBoxは端末のOSを参照し、iOS10.3.3以上の場合はiOS内蔵のレビュー依頼ウィンドウを表示します。その場合、自作のウィンドウを用意していてもiOS内蔵のウィンドウが優先的に表示されます。 ここで注意する必要があるのが、仮にこの設定を行っていても、ビルドに用いるXCodeのバージョンが8.3未満の場合、iOS10.3に対応していないためiOS内蔵のレビュー依頼ウィンドウが表示できない点です。 また、iOS内蔵のレビュー依頼ウィンドウは SKStoreReviewController というiOSのSDKを使用しており、365日あたり3回までしかレビュー依頼ウィンドウが出せません。これは、Apple側の「ユーザーに執拗にレビューを求めるのは良いことではない」という考えに基づいた仕様です。 このため、iOS10.3.3以上の場合、 RateBoxConditions の条件を完全にクリアした状態でレビュー依頼ウィンドウを出そうとしても表示されないことがあります。従って、Appleは「ボタンを押したら必ずレビュー依頼ウィンドウが出る」など、ユーザーの動作に直結したレビュー依頼の出し方をすることは望ましくないと表明しています。(詳細はこちら)

4.レビュー依頼の表示
 レビュー依頼を出したいタイミングで RateBox.Instance.Show() を実行することで、RateBoxがレビュー依頼のウィンドウを表示してくれます。
引数も存在しますが、引数はRateBoxに備え付けのUIでレビュー依頼ウィンドウを出す際の各種テキストなので、自作ウィンドウの場合はウィンドウ側で文字列の制御をし、引数は渡さなくても大丈夫です。
また、RateBox.Instance.ForceShow() という関数も存在し、こちらは RateBoxConditions で設定した条件を無視して必ず表示させる関数です。使用の際は、前述のiOS10.3.3以上のSDKの制限に注意しましょう。

5.レビューのコールバック
 残念ながら、レビュー依頼ウィンドウで「レビューする」を押した場合、実際に遷移先でレビューしたかどうかのコールバックは存在しません。
すなわち、少なくともRateBoxでは「レビューしてくれたらアイテムを差し上げます」タイプの実装は出来ないということです。
ただ、そもそも報酬を目当てにレビューさせることは各ストアの規約に違反する恐れがあるため、望ましいことではありません。

6.統計情報の削除
 RateBoxConditions で設定した条件の統計情報(カスタムイベントの回数など)は、 RateBoxStatistics クラスに保持されています。
何らかの目的でこの統計情報をリセットしたい場合、 RateBox.Instance.ClearStatistics() を実行します。
ちなみに、この統計情報はアプリのバージョンが更新されたり、アンインストールされたりすると削除されます。
このため、「二度と表示しない」を押したり、カスタムイベントを達成して表示されない状態になったユーザーに対して、アプリのアップデートをすることで再度レビュー依頼を出すことが出来ます。

さいごに

基本的な使い方は以上になります。
最後に、RateBoxのドキュメントに記載されているこの一文を載せておきます。

Call Show function when user is satisfied (level up, complete the stage, receive bonus, etc).

レビュー依頼は、適切なタイミングで表示しないとかえってアプリの評価を落とすことに繋がりかねません。
ユーザーがレビューをしたくなるタイミングを考え、アプリの構造・システムに応じて、最適なレビュー依頼を行えるように各種条件を使いこなしましょう。

デスクワークと長く付き合っていくために意識したい3つのこと

0

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

デスクワークをされている方は、一日の中で座っている時間が一番多いかと思います。
座るのは楽というイメージがある方もいるかもしれませんが、
長時間座り続けるのは立っている以上に体に負担がかかるとも言われています。

そんなデスクワークと長く付き合っていくために、意識したいことを3つご紹介します。

①正しい姿勢を保つ

enter image description here
猫背、足組み、頬杖、斜め座り…作業に集中するとつい姿勢を崩してしまいがちです。
悪い姿勢は、腰痛や肩こりを引き起こす原因になります。

体が痛み始めると集中力がとぎれがちになり、作業効率も落ちてしまいます。
よって、正しい姿勢を保つことは作業効率の向上につながります。

骨盤を立て、背筋を伸ばして座るように心がけましょう。
意識してもなかなか姿勢が直らない!という方は姿勢矯正椅子の使用をおすすめします。
座るだけで自然と背筋が伸びる構造になっているため、無理なく姿勢を正すことができます。

②座りっぱなしはNG

enter image description here
長時間同じ体勢でいると血行が悪くなったり、筋肉がコリ固まってしまいます。
体の痛みの原因になるだけでなく、早期死亡のリスクも高まると言われています。

集中するあまり一日中座りっぱなしで作業をしてしまったことはありませんか?
立ち上がった直後うまく体が動かず、体が緊張してしまっているのを感じます。

眠気覚ましやリフレッシュも兼ねて時々立ち上がって歩いたり、
座ったままでも思い切りのびをしたり、肩を回したり、体をひねったり…
本格的なストレッチでなくとも、やるとやらないでは体の調子が大きく変わります。
2時間に1度は軽い運動を含めた休憩をとるようにしましょう。

③目を大切にする

enter image description here
デスクワークはパソコンと長時間向き合うため、目に疲れがたまります。
機械のディスプレイから放たれるブルーライトは目にダメージを与えます。
作業をするときはブルーライトカット眼鏡を使用し、目へのダメージを軽減すると良いでしょう。

カット率の高いメガネのレンズは黄~橙色をしているため、景色の色が目に見えて変わります。
グラフィックを扱う作業の場合は注意が必要です。

enter image description here

疲れた目を休ませるときにはホットアイマスクがおすすめです。
目元の筋肉を温めることでコリをほぐし、疲れを癒してくれます。
使い捨てタイプや繰り返し使えるタイプ、電気充電式のものまで様々な商品が展開されています。

また、ホットアイマスクと同様の効果を持つ蒸しタオルを自宅でも簡単に作ることができます。
タオルを水で濡らしてしぼった後、そのままレンジで30秒〜1分加熱するだけで完成です。
取り出した直後はかなり熱くなっているため、やけどには十分注意してください。
作業中はもちろん起床後の眠気覚ましに、就寝前のリラックスタイムにもおすすめです。

おわりに

デスクワークにおいて自分が日々実践していることを書かせていただきました。
簡単なことですが、少し気を付けるだけで体への負担が大分減っているように感じられます。
健康あっての生活ですから、体を大切に暮らしていきたいですね。

MonoDevelopにコーディング規約を設定する

0

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

Unityをインストールする際に(特に設定しなければ)付属してくるIDE「MonoDevelop」でコーディング規約を設定する方法をご紹介いたします。

はじめに

気がついたらもう春ですね。
春になると、卒業研究を終えた内定者たちのインターンシップ参加率が上がり、それに伴ってプロジェクトに新しいエンジニアが来てくれます。
自分は今まで新卒という立場で、先輩方に色々と教わりながら1年間業務を行ってきたわけですが、そんな自分にも後輩ができるみたいです。全然実感がありません。

さて、後輩たちの環境構築やプロジェクトの説明をする際に忘れてはならないのが、コーディング規約についてです。
変数名の付け方やプログラムの構造だけでなく、改行、スペース、インデント等もプロジェクト間で揃えないと読み辛いソースコードが出来上がってしまいます。

とはいえ、開発経験が乏しい場合でも、なんとなく自分の慣れ親しんでいるコードの書き方というのはあるかと思います。
そんな状態で、「お前は今日からこのプロジェクトの一員だ、この規約に従ってコーディングしろ」と言われても(※実際にはそんな言い方はしません)、ただでさえ不慣れな環境の中、気を遣うことが多すぎて集中できないと思います。

そこで、Unityに標準でついてくるIDE「MonoDevelop」の機能を使えば、他の人が作ったコーディング規約をインポートしてコードを自動整形することができます。

やり方

[MonoDevelop-Unity] 
-> [Custom Policies...] 
    -> Add Policy 
        -> From file... 
            -> 拡張子「.mdpolicy」のファイルを選択
enter image description here

上記の手順を踏むと、.mdpolicyファイルを読み込んでコーディング規約を生成してくれます。

.mdpolicyファイルとは

.mdpolicyファイルの中身を見てみると、以下のようになっています。

  <NameConventionPolicy>
    <Rules>
      <NamingRule>
        <Name>Namespaces</Name>
        <AffectedEntity>Namespace</AffectedEntity>
        <VisibilityMask>VisibilityMask</VisibilityMask>
        <NamingStyle>PascalCase</NamingStyle>
        <IncludeInstanceMembers>True</IncludeInstanceMembers>
        <IncludeStaticEntities>True</IncludeStaticEntities>
      </NamingRule>
      <NamingRule>
        <Name>Types</Name>
        <AffectedEntity>Class, Struct, Enum, Delegate</AffectedEntity>
        <VisibilityMask>VisibilityMask</VisibilityMask>
        <NamingStyle>PascalCase</NamingStyle>
        <IncludeInstanceMembers>True</IncludeInstanceMembers>
        <IncludeStaticEntities>True</IncludeStaticEntities>
      </NamingRule>
      <NamingRule>
        <Name>Interfaces</Name>
        <RequiredPrefixes>
          <String>I</String>
        </RequiredPrefixes>
        <AffectedEntity>Interface</AffectedEntity>
        <VisibilityMask>VisibilityMask</VisibilityMask>
        <NamingStyle>PascalCase</NamingStyle>
        <IncludeInstanceMembers>True</IncludeInstanceMembers>
        <IncludeStaticEntities>True</IncludeStaticEntities>
      </NamingRule>

...以下省略

このように、命名規約やインデント規約などが細分化された状態でxml形式で記述されています。
これをプロジェクトの共有フォルダ等に置いておくことで、誰でも簡単にプロジェクトのコーディング規約を設定することができます。

.mdpolicyファイルの作り方

さて、.mdpolicyファイルですが、当然プロジェクト間で共有するためには誰かが最初に作成しないといけません。
理論上、先ほどの例のような感じでxml形式で記述したファイルを.mdpolicy拡張子で保存すれば作成できますが、果てしなく面倒な作業ですね。

当然ですが、MonoDevelopはインポートだけでなくエクスポートもできます。
もちろん、xmlを書かなくても、MonoDevelop上で各規約の設定を行って保存することができます。

enter image description here
先ほどインポートの際に説明した画面の左側のメニューから、

[Source Code] -> [Code Formatting] -> お好みの形式

を選び(今回はC#)、画面右側で 「C# Format」を選択し、Editを押すと

enter image description here

このように、各種規約に対するパターンがずらっと並んだ画面が表示されます。
ここでチェックボックスをいじったりして、右側のプレビューを参考にしつつ簡単に規約を設定できます。

そして、無事に規約を作成し終えたら、先ほどの 「Add Policy」の右にある「Export」でファイルに出力しましょう!

ファイル保存時にフォーマットを行う

最後に、ファイル保存時に自動でフォーマットを行ってくれる機能をご紹介します。

enter image description here
[MonoDevelop-Unity] -> [Preferences] -> Text Editor -> Behaviour 

の、「Format document on save」にチェックを入れて保存しましょう。

これで、ファイルを保存した際に自動的に設定された規約に基いてコードを整形してくれます。

以上、MonoDevelopにコーディング規約を設定する方法でした。

選択肢で読み手を引き込む

0

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

以前の記事で、少しだけゲームでのストーリー演出について触れました。
今回はその続きとして、ゲームならではの表現方法の一つ、「選択肢」についてお話したいと思います。

はじめに

ゲームのストーリー中にプレイヤ―自らが選ぶ選択肢には、単純な「はい or いいえ」のものから、ゲームの流れからプレイヤーが感じたであろう思いが反映されたものまで、多岐にわたります。
用意された通りにストーリーが進んでいく一方で、プレイヤー自身の選択を問われることで、自分がストーリーに参加しているような感覚を味わうことができるのです。

その中でも、選択肢によってその後のストーリー展開が大きく変わっていくものと、そうでないものがあります。
ノベルゲームとして世に出ているゲームでは前者が多いですが、オンラインゲームやソーシャルゲームでは、仕様上ストーリー展開を変えることは難しいです。
そのため、選択肢直後の短いストーリーのパターンが数種類用意されており、その後同じストーリーに合流する、というものが多くなっています。

この記事では後者の、大きく展開が変わらないタイプの選択肢についてお話したいと思います。

選択肢後の小さな変化

どの選択肢を選んでも、結局その後のストーリー展開が変わらないのであれば、選択肢に意味はないのではないか?とお考えの人もいると思います。
ですが、読み手であるプレイヤーに少しでも物語へ介入してもらうことで、よりお話への愛着がわくのではないかと、個人的に考えています。

例として、選択肢なしで進行する想定の画像を用意しました。

enter image description here
enter image description here

このままでも何の不都合なくストーリーが進行していきますが、今一つ物足りなさを感じます。
キャラクターがプレイヤ―に問いかけるような台詞を言っているのにも関わらず、反応もなしに話が進んでしまっているからです。

では次に、選択肢を選んだ直後のみストーリーが変わる例を見てみましょう。

▼選択肢直前の台詞
enter image description here

▼選択肢登場
enter image description here

▼上の選択肢を選んだ場合
enter image description here

▼下の選択肢を選んだ場合
enter image description here

▼共通ルートへ合流
enter image description here

このように、問いかけがない状態で話が進行していくよりも、キャラクターがプレイヤー自身に語り掛ける形を作り、プレイヤーが選んだ選択肢に対してキャラクターの反応が変わることで、よりストーリーに入り込みやすくなります。

選択肢を有効活用すれば、ストーリーへの没入感をより高めることが出来るのです。
こういった選択肢以外にも、推理系のお話ならばプレイヤ―自身に答えを選ばせる、といった使い方もできます。

最近では、思わず笑ってしまうような小ネタが選択肢に仕込まれているケースも多く、笑いのセンスの見せ所でもありますね。

終わりに

私は選択肢後の反応を全て回収したいタイプなので、選択肢が非常に多いゲームをやるときはとても時間がかかります。
その分、キャラクターの色々な面を見ることが出来てとても楽しいですし、より強くキャラクターへの愛着をもてます。
いつも何気なくストーリーを飛ばし読みして、選択肢を適当に選んでいる方も、ストーリーそのものをスキップしてしまう方も、この機会にストーリーをじっくり読んでみると、新たな発見があるかもしれません。

画像作成には
ティラノビルダー

いらすとや
以上を使用いたしました。

一貫性の原理について

0

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

一見すると命名規則なんかの原理っぽく感じますが、今回はビジネス系の記事です。
ちょっと街角でアンケートに答えていたはずが、気づいたら壺を買わされていた。なんて話を聞いたことがあるかもしれません。
これは一貫性の原理を用いたセールス方法だと言われています。フット・イン・ザ・ドア・テクニックと言い換えるともっと分かりやすいかもしれないです。
フット・イン・ザ・ドア・テクニックがどんなものかというと、大きい頼みごとをする前に小さい頼みごとをしてOKを貰うと、そのあとの大きい頼みごとを受け入れられやすくなるというものです。
これはセールスが玄関に足先を入れる様子が語源です。最近では見ない光景ですが。
俗説っぽい話ですが、初出は1966年の社会心理学のジャーナルで、それ以降も研究されていることなので一応ちゃんとした原則のようです。
大きい頼みごとをする前には、受け入れられやすい頼みごとをする。これがポイントです。
人は一旦決めたことに対して、決定を覆すというのが苦手なんですね。
なので当初の約束と違ったことでも、一度受け入れてしまうと次々と受け入れてしまいます。
お金のかからない運動会をするはずが、会場を壊して立て直すところから始まってしまうわけです。

さて、ここまではセールスの話でしたが、一つ視点を上げて、ぼくの学んでいた経営学から一貫性の原理について話します。
サンクコストについてです。
サンクコストとは、その時点で事業などをやめても戻ってこないコストのことです。お金や時間などですね。
ある事業に対して大きな投資をしているときに、その事業が間違っていると気づいたときでも、既に投資している金額が大きいため、手を引くことができない。といった文脈でサンクコストが出て来る場面が多いです。
この例であれば、合理的な意思決定は事業をやめてしまうことです。
サンクコストと期待投資収益に相関はないので、サンクコストは本来考慮されるべきではない。というのが合理的な判断ですね。

さて、2つの例で一貫性の原理について書きましたが、人は様々なバイアスによって合理的な判断ができないというのが現在では明らかになっています。
この点では心理学よりも行動経済学の方が今では盛んかもしれないですね。
バイアスを除いて合理的な意思決定をすることは、日頃の買い物のような場面においても、会社などの大きな場所でも意識しておいていいのではないでしょうか。

Ruby×PyCallでTensorflowのMNISTチュートリアル

0

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

PyCallを登録RubyからPythonのノを呼べでにできので、TensorflowのOKのチュートリアルであるMNISTデータセットの画像分類を上みました。

はじめに

がさまお
久しいうです、くろすです。新入を名乗せのももてなりなりますが、、今は表3年は新発策でひたすら研究をしてください。


学生時代座でガリガリ微してMATLABのコードに実してDNN作したのがアホらしくててますます。。ししくちゃ今更感ありますが、RubyからPyCallをててて。

ルビーでデータサイエンス

あり前はかかでありでかかかでありがれいたのですがルビーはそれでありをする
ははははははははははははははははははははははははははははははははははははははははははははははははははははははははははははははははは
はを何とかする」
劣目は「Ruby望のデッキをする」

巨人の肩の上でるる」並べ方法でルビーから機械学習をやりたいと思います。

環境

$ルビー-v
ruby 2.5.0p0(2017-12-25リビジョン61468)[x86_64-darwin16]
$宝石リスト| grep pycall
pycall(1.0.3)

$ python3 -V
Python 3.6.4
$ pip3フリーズ| grep tensorflow
tensorflow == 1.6.0

ルビーのコード

今回やったチュートリアルはtensorflowのバージョンR1.2のチュートリアルのうちMNISTを使ったやつです。
https://www.tensorflow.org/versions/r1.2/get_started/mnist/beginners

tensorflowの失格1.6.0でもちゃんと勢なり。

必要「pycall 」
必要「pycall /インポートを」

モジュール Pythonは
  延びPyCall ::インポート
  クラス<<自己
    DEF から(パス、インポート:ゼロ)
      pyfrom path、import:import
       self .send import
     end

    def  method_missing(method_name)
      pyimport method_name
      self .send method_name
     end 
  end 
end
require_relative 'のpython '
#Pythonのライブラリのインポート
Pythonの.from(' tensorflow.examples.tutorials.mnist '、輸入::INPUT_DATA)
tf = Python .tensorflow
input_data = Python .input_data


#MMISTデータセットをダウンロードmnist = input_data.read_data_sets(' MNIST_data / '、one_hot:true)

#入力、重み、バイアス
x = tf.placeholder(tf.float32、[ nil、784 ])
W = tf.Variable.new(tf.zeros([ 784、10 ]))
b = tf.Variable.new(tf.zeros([ 10 ]))

#出力
y = tf.nn.softmax(tf.matmul(x、w)+ b)
y_ = tf.placeholder(tf.float32、[ nil、10 ])

#エラー関数
cross_entropy = tf.reduce_mean(-1 * tf.reduce_sum(y_ * tf.log(y)、reduction_indices:[ 1 ]))

#鉄道模型
train_step = tf.train.GradientDescentOptimizer.new(0.5).minimize(cross_entropy)

sess = tf.InteractiveSession.new
tf.global_variables_initializer.run

#電車は開始
1000年.times行う
  バッチ= mnist.train.next_batch(100)
  batch_xs、batch_ys = batch [ 0 ]、batch [ 1 ]
  sess.run(train_step、feed_dict:{x ​​=> batch_xs、y_ => batch_ys})
 end

#正規化
correct_prediction = tf.equal(tf.argmax(y、1)、tf.argmax(y_、1))

#結果
精度= tf.reduce_mean(tf.cast(correct_prediction、tf.float32))
puts sess.run(accuracy、feed_dict:{x ​​=> mnist.test.images、y_ => mnist.test.labels})

わざわざPythonザル呼切り改善のはmath.rbとかれてて目してた名残になる、たはtensorflow_tutorial.rbにベタ書きする問題なしです。

結果

$ ruby​​ tensorflow_tutorial.rb
0.9185

これは約92%になるはずです。

戦略に正回答率92%これになりました。

浄化所

pycallが富士に行くpythonが/ usr / bin / python

環境変数PYTHONを使いたいpythonにすどいい

$ export PYTHON = path / to / python3

データセットダウンロード連結SSL評価でエラー

$ / Applications / Python \ 3.6 / Install \ Certificates.command

で解決
参照(https://github.com/tensorflow/tensorflow/issues/10779

tf.matmul(x、w)でなんかエラーでた

例外:PyCall :: PyError:<class'TypeError '>:_ as_graph_element()に1つの必須の位置引数がありません:' self '
ファイル「/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/tensorflow/python/ops/math_ops.py」、2004行、matmul
  名前としてops.name_scope(name、 "MatMul"、[a、b])を使用:
ファイル "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/tensorflow/python/framework/ops.py"、行5616、__ enter__
  g = _get_graph_from_inputs(self._values)
ファイル "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/tensorflow/python/framework/ops.py"、5277行目、_get_graph_from_inputs
  graph_element = _as_graph_element(op_input)
_as_graph_elementのファイル「/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/tensorflow/python/framework/ops.py」、118行目
  conv_fn()を返します

まだの部分をルビーコードにません

pythonの元コード:tf.Variable(tf.zeros([10]))
間麻えたるちコード:tf.Varialbe(tf.zeros([10]))
改善ルビーコード:tf.Variable。(tf.zeros([10]))

よくPyCall使ってルビーで…ってる記事にはtf.Variable.(tf.zeros([10]))のように書いてるあのりますが、これはtf.Variableクラスの()メソッドを呼んでいる、つまりコンストラクタの呼び出しなのでルビー的に書くならイニシャライザを呼び出してあげれば良いん
消。じゃあおりHDLです。

正解のルビーコード:tf.Variable.new(tf.zeros([10]))

連想配列の説明手間戦略た

元のPythonコード:sess.run(train_step、feed_dict = {x:batch_xs、y_:batch_ys})
Rubyデッキコード:sess.run(train_step、feed_dict:{x:batch_xs、y_:batch_ys})
Ruby正解コード:sess.run(train_step、feed_dict:{x => batch_xs、y_ => batch_ys})

終わりに

PyCallをててRubyからtensorflowを押してMNISTのチュートリートたたて記事がぱっと見たたたたので書たたたたので書たみました。
今回はわざわざPyCallを使ってルビーからtensorflowを触りましたが、実はtensorflow.rbというRubyAPIがあったりするので、次はそっち使って遊んでみます。

tryの使い方と注意点

0

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

Railsのtryを使用するにあたってのアドバイスを頂いたので、今回は、tryについてまとめてみました。

tryとは?

 簡単に説明すると、レシーバがnilでもNoMethodErrorが発生せずに、nilを返してくれるメソッドです。このメソッドは、railsのactivesupportというgemをインストールすると使用することができます(ほとんどの場合、Railsの環境構築をすると入っています)。tryの細かい動きについては、自分の環境のactivesupport4.1.4のコードが分かりやすかったので、こちらのコードを使用して説明していきます。※バージョンによっては、処理内容が異なる可能性があります。(githubのactivesupportのコード:https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/object/try.rb)

activesupport-4.1.4/lib/active_support/core_ext/object/try.rb

class Object
  def try(*a, &b)
    if a.empty? && block_given?
      yield self
    else
      public_send(*a, &b) if respond_to?(a.first)
    end
  end

  def try!(*a, &b)
    if a.empty? && block_given?
      yield self
    else
      public_send(*a, &b)
    end
  end
end

class NilClass
  def try(*args)
    nil
  end

  def try!(*args)
    nil
  end
end

 見て貰えれば分かりますが、レシーバがnilの場合は、引数に関わらず必ずnilが返るようになっています。次に、レシーバがオブジェクトの場合のtryとtry!の違いに注目してみます。tryは、respond_to?でメソッド名が正しくない場合に、メソッドを実行しないので、エラーが発生しませんが、try!は、respond_to?が無い為、メソッド名が正しくない場合は、NoMethodErrorが発生してしまいます。

 下記のクラスとデータを使用してtryを使用した簡単な例を挙げます。(Person.job_idは、Job.idの外部キー)

class Job < ActiveRecord::Base
  has_many: persons
end

class Person < ActiveRecord::Base
  belongs_to: job
end
enter image description here
# Aさんの仕事を取得
person_a = Person.find_by(name: 'A')
person_a.job.job_name
=> engineer

# Bさんの仕事を取得
person_b = Person.find_by(name: 'B')
person_b.job.job_name
=> NoMethodError # Bさんは仕事(job_id)を持っていないので、仕事名を取得すると、NoMethodErrorが発生します。

# tryを使用すると、NoMethodErrorを回避することができます。
person_b.job.try(:job_name)
=> nil

tryをチェインするときの注意点

 tryをチェインするときは、原則tryを使用します。レシーバがnilでもエラーが出ないto_spresent?メソッドなどの場合のみtryを使用しなくても良いです。tryは、レシーバがnilになる可能性がある場合に使用する為、tryの後にnilで動かないメソッドを記述するとエラーの原因となります。

person_c = Person.find_by(name: 'C')

# 悪い例
person_c.try(:job).job_name
person_c.try(:job).try(:job_name).swapcase

# 良い例
person_c.try(:job).try(:job_name)
person_c.try(:job).try(:job_name).try(:swapcase)
person_c.try(:job).present?

番外編 「筆者が物事を始めるときに気にする事柄」

0

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

番外編 「筆者が物事を始めるときに気にする事柄」について話していきたいと思います。

みなさん!こんにちは!Lionです。
前回の記事いかがだったでしょうか?
「モンスターハンターワールドの面白さに迫れ!」という記事で、少しでもモンハンの面白さが伝われば幸いです。
さて、本日は番外編です。
「筆者が物事を始めるときに気にする事柄」について話させていただきます。
※筆者の考え方が大いに入っていますので、「こんな考え方もあるんだ!」という参考程度になれば嬉しいです。

「ゼロの線」で物事を考えてみよう!

世の中に沢山いると思いますが、「新しく何かを始めようとすることがめんどくさい」、「違う環境に変わるのが怖い」などなど…。
個人的には、その考え方は「凄くもったいない」と思います。理由としては、生産的ではないからというところが大きいです。
そこで、筆者が考える「ゼロの線」について説明しますと
enter image description here
ゼロの地点は自分が何か始めるときの起点とします。そこから、どんな理由であれ、新しいことに取り組むと大なり小なりありますが、「生産的な思考」にどんどんなっていきます。
たとえ、新しいことにつまずいて失敗してもゼロ以下にはそう簡単になりません。なぜなら、一度前向きにした+思考はその後も続けて持続できることが多いからです。
しかし、その逆で理由を付けて新しいことにチャレンジしない人は「非生産的な思考」に陥ります。
これを続けてしまうと、どんどんやる気を失っていきますし、最悪鬱にもなります。
また、ゼロ以上に思考を伸ばすのがとても難しくなってしまい負の連鎖が生まれやすくなってしまいます。
そういう思考に陥ってしまっている人たちへ、私が言いたいこととして「失敗してもいいじゃない?行動することに意味があるし、行動した分だけリターンも返ってくるし、無駄にはならないよ!」と。

ここまで話してみて

いかがだったでしょうか?
今回は私の思想論的な話になってしまいました。
ちなみに私自身、色々苦汁を沢山体験してきてこの思考に至りました。
もっとぶっちゃけると、「自分が主人公の物語は今しかないんだからもっと大暴れしようぜ!」というのが一番大事かなと思います。
「人生は1度のみ!どう行動して自分を+で価値の高い人物になるかを楽しむゲーム」だと思ってます。
今、-思考に陥ってる方がいれば、ぜひ「ゼロの線」を考えてみてください!
さて、次回も番外編です。「食生活って意外と大事!?」という内容を記事にして書いていきたいと思います(笑)
健康診断で「食生活を改善しましょう?」と言われてしまったので自分への戒めも込めたいかと…w
では、またねー(´・ω・`)ノシ

構造化マークアップでSEO対策!

0

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

SEO対策として構造化マークアップを行ったので備忘録として記事にします。

はじめに

約1か月ぶりの更新になります。
あと数日で新卒が入ってくると気づいて1年経つ速さに置いてかれそうになっているむらさきです。
今回はSEO対策で行った構造化マークアップについて書きたいと思います。

SEOとは

SEOとはSearch Engine Optimization(検索エンジン最適化)の略で、これを行っていくことGoogleなどの検索結果で最初のページに出てくるようになり、沢山の人に見てもらえるようになります。
SEO対策の方法はたくさんあるのですが今回は「構造化マークアップ」について書いていきます。
他のSEO対策などは自分より詳しい人たちが記事を書いているので、当ホームページのSEOカテゴリもぜひご覧ください!(SEOカテゴリへ)

構造化マークアップとは

HTMLに書かれている文字列は何を意味しているかの情報は持っていません。人の名前かもしれないし、地名かもしれない。はたまた見出しのタイトルかもしれません。人間であれば「ここにはこういう内容が書かれているんだろうな」と推測することができますが、検索エンジンはそこまで理解できません。しかし「ここには人の名前が書いてあるよ!」「こっちは住所だよ!」と教えてあげれば検索エンジンは素早くページを理解してくれます。

構造化マークアップを行うとどうなる?

構造化マークアップを行うと検索エンジンに情報が適切に伝わり、検索結果ページでの表示がリッチスニペットで表示される可能性があります。
リッチスニペットとは検索結果画面で通常出てくるリンクと数行の説明テキストの他にレビューやクチコミ、サムネイル画像などの情報が一緒に表示される状態のことです。
構造化マークアップを行うことで必ずリッチスニペットで表示されるというわけではありませんので、他の有効的なSEO対策がある場合はそちらから行った方が良いと思いますが、リッチスニペットで表示されることでより多くの人の目に留まることができるので是非やっておきたいSEO対策になると思います。

実際に書いてみよう

構造化マークアップについて理解を深めたところでどのように記述すればいいかを見ていきましょう。
まずはGoogleの検索エンジンが理解できるフォーマットで記述していきます。
フォーマットにはボキャブラリーとシンタックスがあります。
ボキャブラリーとは「この値はこれを指しています!」「こっちはこういうものです!」という風に検索エンジンが分かる言語で定義されているものです。

  • data-vocabukary.org
  • schema.org

があります。

シンタックスとは記述方法でこの書き方に沿って書く事で正しく検索エンジンに理解してもらうことができます。

  • microdata
  • RDFa
  • JSON-LD

の3つがあります。今回はGoogleが一番推奨しているとされるJSON-LDを使用したschema.orgで記述していきたいと思います。(schema.orgで定義されているリストはこちら)

今回はこの記事(Article)用の構造化マークアップを例に書いていきたいと思います。HTML内であればどこに記述しても問題ありません。

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "Article",
  "headline": "構造化マークアップでSEO対策!| SEO | DoRuby",
  "datePublished": "2018-03-26",
  "dateModified": "2018-03-26",
  "publisher":
  {
    "@type": "Organization",
    "name": "DoRuby",
    "logo": 
    {
      "@type": "ImageObject", 
      "url": "https://doruby.jp/assets/logo-254272aab3fa84603b6f1a8e78028ff55d9ae486f1f1fe69f4aeb9a5022dfe59.png",
      "width":
      {
        "@type": "Intangible",
        "name": 165
      },
      "height":
      {
        "@type": "Intangible",
        "name": 44
      }
    }
  },
  "about": "SEO対策として構造化マークアップを行ったので備忘録として記事にします。",
  "articleBody": "約1か月ぶりの更新になります。",
  "image":
  {
    "@type": "ImageObject",
    "url": "https://doruby.jp/uploads/entries/1315/9ca404d30c733ba0ab9493d2d114d4ab.jpg",
    "width":
    {
      "@type": "Intangible",
      "name": 720
    },
    "height":
    {
      "@type": "Intangible",
      "name": 479
    }
  }
  "author":
  {
    "@type": "Organization",
    "name": "株式会社アピリッツ"
  },
  "mainEntityOfPage":
  {
    "@type": "WebPage",
    "@id": "https://doruby.jp/users/ueki/entries/%E6%A7%8B%E9%80%A0%E5%8C%96%E3%83%9E%E3%83%BC%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97%E3%81%A7SEO%E5%AF%BE%E7%AD%96%EF%BC%81"
  }
}
</script>

今回はこんな感じで書きました
最初に書いた“@context”は使用するボキャブラリがあるurlを指定しています。
途中でちょくちょく入ってくる“@type”はボキャブラリのリストに定義されている内容を指定しています。(Articleなら記事、ImageObjectなら画像ですよ!と検索エンジンに教える役割を担っています)
“@type”はかなり細かく分けられているので自分が構造化マークアップがしたいページの内容とボキャブラリリストを照らし合わせながら書くといいと思います!

確認してみよう

構造化マークアップが上手く行えているかを確認するにはGoogleが提供している構造化データ テストツールを使用します。
すでに公開されているURLであればURLを入力することで正しくマークアップが行われているかを確認できます。
まだ公開されていないURLやテスト環境等の検索エンジンのbotがクロールできない環境ではURLで確認することはできません。
その代わり下記画像のようにコードスニペットにコードを直接記述することで確認することができます。
enter image description here
「テストを実行」を押下することで正しくマークアップされているか、エラーや警告がないかを確認することができます。
“@type”によっては入力必須のものもあったりするので細かくテストで確認しましょう!

おわりに

いかかだったでしょうか。弊社のSEO対策チームから業務で構造化マークアップを指示されて初めて存在を知って、調べながら実装をしていたのですが皆さんに共有できていれば幸いです。
それではまた次の記事でお会いしましょう!むらさきでした!

番外編 「食生活って意外と大事!?」

0

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

番外編 「食生活って意外と大事!?」について話していきたいと思います。

みなさん!こんにちは!Lionです。
前回の記事いかがだったでしょうか?
「筆者が物事を始めるときに気にする事柄」という記事で、少しでも前向きな考えを持っていただけるようになったらとても嬉しいです。
さて、本日も番外編です。
「食生活って意外と大事!?」について話させていただきます。皆さんもきちんとした食生活をしていますか?
毎日、炭酸飲料を1.5ℓ飲んだりしていませんか?食生活を乱すは人生を乱す(名言)と言われるくらい大事なので一緒にきちんとした食生活ってどういう風な物か勉強していきましょう。
※健康診断で指摘されて、戒めに書いています(´;ω;`)

規則正しい食事をする習慣をつけよう!

   enter image description here
みなさん、毎日三食きちんと食事していますか?私はしていないです。
特に、朝ご飯を食べない傾向にあります。
ちなみに朝ご飯が大事なのは「朝から勉強や仕事で高パフォーマンスを出せるようにするため」だそうです。
理由としては、糖質は脳の唯一のエネルギー源で、朝食をきちんと食べると、活動に必要なエネルギーが体にいきわたり、体も脳もしっかりと働ける状態になるからですね。

ちなみに偏った回数の食生活をすると、必要な栄養素が十分にとれなくなってしまうことがあったり、1回の食事でつい食べ過ぎてしまい、肥満になりやすくなってしまったりします。
そのため、食事は一日3回、きっちり規則正しくとるのがベストですね!

美味しいからって取りすぎは注意!

             enter image description here
みなさん、焼き肉は大好きですか?僕は大好きです。
ラーメンも寿司も大好きです。毎日食べていたいくらいです。
でも、これらの高カロリーな食べ物を食べすぎると病気になってしまう恐れがあります。
特に脂質と食塩は要注意です…。理由としては

①脂質
とりすぎると肥満、メタボリックシンドローム、糖尿病などの生活習慣病の原因になります。
特に不飽和脂肪酸は冠動脈疾患のリスクを増加させる恐れがあるので、 揚げ物や脂っこいものばかり食べないようにする、サラダ油やバター、マーガリンなどの「見えるあぶら」だけでなく、お菓子、肉、魚などに含まれる「見えないあぶら」もとりすぎないように注意が必要!

②食塩
摂取しすぎると、高血圧や胃がんになりやすくなります。一日にとる量は、成人の男性は8グラム未満、女性は7グラム未満が良いと言われているらしいです。
塩辛い食品を控える、麺類の汁を残す、味付けに香辛料や酢、かんきつ類などを上手に利用するなど、塩分をとりすぎないよう工夫して食塩過多をしないように気をつけないといけない!

糖尿病や胃がんになるのは恐ろしいですね|ω・)

ここまで話してみて

いかがだったでしょうか?
改めて考え直してみると、きちんとした食生活をしたほうが、歳を取った時に苦労しないかなと思いました。
これからは、きちんとした食生活をして健康を保っていきたいと考えを改めました。

さて、次回は第12回「PUBGってなんだ!?最近流行りのバトルロワイヤルゲームとは?」という内容を記事にして書いていきたいと思います。
ではでは、またねー(´・ω・`)ノシ

第12回「PUBGってなんだ!?最近流行りのバトルロワイヤルゲームとは?」

0

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

第12回「PUBGってなんだ!?最近流行りのバトルロワイヤルゲームとは?」について話していきたいと思います。

みなさん!こんにちは!Lionです。
前回の記事いかがだったでしょうか?
「食生活って意外と大事!?」という記事で、筆者と共に食生活を改めようかなと思ってくれる人がいましたら幸いです。

さて、本日は「PUBGってなんだ!?最近流行りのバトルロワイヤルゲームとは?」について話させていただきます。
私も2日前に、この手のゲームを友人に勧められて始めてみたところ、超絶面白くてプレイしまくっています(笑)
そんなPUBGの魅力を皆さんに伝えていければいいかなと思います(*‘∀‘)

PUBGってそもそもどんなゲーム?

PUBGっていう「ゲームは最大100人のプレイヤーが無人島で最後の一人になるまで戦い続けるバトルロワイヤル形式のサバイバルゲーム」です。

無人島でやることは主に

①現地の無人島で武器や防具、回復アイテムなどを採取!
②服などを着てお好みのキャラにカスタマイズ!
③廃墟に罠などを貼って籠城して身を守る!
④敵をひっそり倒すか密集している場所にあえて突っ込んでいって殲滅する!
⑤廃墟で武器収集やレアアイテムを探したり!

みたいな感じですね!
特に良い武器を探す旅が個人的に楽しいですね。
で、良い武器が集まったら廃墟に立て籠って、人数減るまで待ち伏せ作戦が一番効率がいいです(笑)

他の射撃ゲームとの違いは?

普通の射撃ゲーム(いわゆるFPS)との違いは、死んでもリスポーンできるかできないかですね。
PUBGはあくまで、最後の1人になるまで生き残らなければならないというのが絶対のルールです。
なので、倒されてしまったらもうそのラウンドには参加できません。
なかなかシビアです。その分、ゲーム中の緊張感も半端ないのでハラハラドキドキして楽しいですね!

初心者が周りのユーザーに追いつけるの?

ゲーム開始時は、みんな同じ条件となります。
上記でも言いましたが、武器や防具、アイテムなどは現地で調達します。
経験値を稼ぐことや、課金して強い武器を持っている人の方が有利、といったことはありません。
ゲームに求められるのは99%のプレイやスキルと1%の運になります(笑)
そのため、初めてゲームをプレイした初心者の方が、ビギナーズラックで最後の生き残りになることだって全然ありえます。
※ちなみにすぐに上手くなりたい方は、操作方法を敵に見つからない場所で覚えたりするのが、上達への近道となります。

ここまで話してみて

いかがだったでしょうか?
ゲーム自体が非常にシンプルなため紹介分が短めになってしまいました。

ちなみに、自分は「Fortnite」というPUBGに似たゲームをやっています。
初めて2日目ですが、もう最後の生き残り5人の中にはいれるようになりました。
射撃ゲームが苦手な人でも手軽に遊べるので、敷居はかなり低いと思います!
もし興味があったら、プレイしてみてください!

さて、次回は番外編「Fortniteのクラフト機能について分析」という内容を記事にして書いていきたいと思います。
ではでは、またねー(´・ω・`)ノシ

よくわからないで使っている英語の意味を知っとこう

0

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

こんにちは。いくたです。
日々の業務ではまだまだ覚えることが多くてあっぷあっぷしています。
知らないことばかりで新しい言葉がどんどん目の前に現れるのですが、そのほとんどが英語をルーツとしたカタカナ言葉や英単語だったりします。
初見では意味不明で「???」状態ですが、ググったり人に聞いたりしてその言葉の指す意味を徐々に覚えています。

しかし、知らない言葉は「おまじない」のように扱ってしまうので、その言葉の本来の意味を知らずに今日までなんとなくで使ってきたものがちょこちょこありました。
ということで今回は、日常的に使っているしその言葉が指す意味も知っているけれど、言葉本来が持つ意味を知らない単語の意味を調べてみました。

以前コマンドラインから英和-和英辞書を引くプログラムを作ったので、せっかくですからこれを使うことにします。ちなみに大元の情報源は英和辞典・和英辞典 – Weblio辞書を使っています。

1. デプロイ(deploy)

deploy

デプロイはプログラムを実際に動く状態にすることです。さっそく辞書を引いてみます。

$ lib deploy
展開する、配置する

なるほど、展開するという意味だったんですね。展開してユーザーが使える状態にするというイメージでしょうか。
deploy=展開するがなんだかしっくりこないのでちょっと踏み込んで語源も調べてみました。

de: 否定
ploy: 折る

 折られていたものを広げて展開する
 【動】展開する、配置する、〈コンピュータ〉デプロイする

参考: Gogengo! (ゴゲンゴ) – 英単語は語源でたのしく

なるほどなるほど、ployが「折る」だったんですね。それの否定で「展開する」ということですね。

2. ターミナル(terminal)

terminal

macに標準で入っているTerminal.appがありますが他のアプリケーションも一般的に「ターミナル」と呼んだりしています。

$ lib terminal
終わりの、末端の、終末の、終点の、終着駅の、末期の、悲惨な、破滅的な、たいへんな、一定期間(中)の

なんだかネガティヴな言葉が沢山出てきましたが、今言いたいterminalは「末端の」が合っていそうです。
調べてみるとつまりは「端末」のことのようです。
なるほど回路の電極のようなデータの入出力をする末端部分のイメージですね。

3. レンダリング(render)

render

Railsではテンプレートの呼び出しをするときにrenderを使います。

$ lib render
(…に)する、する、与える、(…に)差し出す、提出する、(法廷で)言い渡す、下す、(…に)翻訳する、(文・絵で)(…を)表現する、描写する

言葉の意味の幅が広いですが一番イメージに近いのは「(文・絵で)(…を)表現する、描写する」あたりでしょうか。
Weblioの語源の欄を見てみるとさらにこのような意味がありました。

【語源】
ラテン語「返す」の意; 名詞 rendition

なるほど、Railsのリファレンスを読むと、指定したRHTMLを「返す」とあります。
語源そのままの意味なんですね。

4. asc/desc

ascending/descending/describe

SQLやプログラムで昇順・降順を指定するときに使います。時々どっちがどっちかわからなくなりますね。

asc = ascending = 昇順
desc = descending = 降順

$ lib ascending
のぼっていく、上昇的な

$ lib descending
下ってゆく、降下的な、下向きの

MySQLでテーブルに設定されている列の情報を desc {テーブル名} で表示することができます。
自分は最初、降順のdescと混同していました。
しかし、列情報の表示の方はDESCRIBEの略語です。

$ lib DESCRIBE
(…を)言葉で述べる、記述する、描写する、(…を)(言葉で)説明する、(…を)(…と)評する、みなす、言う、描く、描いて運行する

なるほど、同じ略語でも全くの別物だということがよく分かりますね。

まとめ

普段業務をこなす分には今回紹介したような言葉の意味は知らなくてもいいかもしれません。
しかし、言葉の意味を知っておくことでより自分の身に染み込む気がします。
新しい言葉を覚えるときはその本来の意味も一緒に調べるとより早く覚えられるかもしれません。

それでは、今日はこの辺で。
読んでいただき、ありがとうございました。

協力要素のあるゲームにおける初心者について考える

0

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

今回は、協力要素のあるソーシャルゲームにおける初心者について考える。

ソーシャルゲームにおける初心者

 前回の対人ゲーム(格闘ゲーム)における初心者は「ジャンル自体が初めて」であることを指したが、今回は純粋に「弱い」人を指すこととする。
 これは、基本的にソーシャルゲームの協力要素はそれ自体が目的のコンテンツではなく、それによって獲得できるアイテムや装備などが目的であるため、ユーザーにとって重要なのは「味方ユーザーが強いか」の一点に基本的に絞られるからである。

初心者にとっての協力要素

 ソーシャルゲームにおける協力要素と言えば、レイドバトル(※ボス敵を複数のユーザーで倒す)である。最初のうちは初心者でも難なく一人で倒せるのだが、ゲームを進めるうちに到底勝てないボスに出会い、他ユーザーに助けを求める、というのが一般的な流れとなる。
 つまり、初心者にとって協力とは「強い人に助けてもらうシステム」であることが多い。

初心者を助ける意味

 前述した「初心者は強い人に助けてもらう」というのを成立させるためには、助ける側のメリットが必要になる。ユーザーは現金なもので、手間に対する見返りが十分にあれば積極的に行うことは想像に難くない。例えば、以下のようなものが挙げられるだろう。
・1日5回助ければ無償石が貰える
・自発(※自分の意思で特定のバトルを発生させること)回数に制限があるボスと何度も戦える
・助けるごとに、回数や活躍に応じて専用の報酬が貰える

協力要素の利用を更に盤石にするために

 最初に述べたように、そもそもユーザーが求めているのはアイテムや装備といった報酬であって、協力要素自体ではないことを忘れてはいけない。つまり、ここが破綻しているとその協力要素は正常な動きをしなくなってしまうため、気をつける必要がある。

・ワンパン行為
 「バトルに参加して1回殴って後は他人に任せる」という協力ではなく寄生と言える行為は最たる例となる。この対策としては「一定以上のダメージを与えるとより良い報酬が貰える」というような活躍度合いを要求するのが直接的で有効な手段となる。

・自発者と協力者の報酬のバランス
 初心者がバトルの良い報酬を手に入れる手段として「自発者報酬」というのがメインとなる。これは、「自発したから良い報酬が貰える(または出やすい)」というもので、ユーザーが積極的に自発する要因となる。一方、「協力者報酬」とはMVP報酬なども含めた参加者の報酬であり、こちらは積極的に助ける要因となる。
 この「自発者報酬」「協力者報酬」のバランスが悪いとどちらかにユーザーが偏ってしまう。どちらかに偏れば「誰も助けに来ない」「助けたくても相手がいない」という過疎やストレスを感じる状態となり、協力要素に対する悪印象へと繋がってしまうので、きちんとバランスを組む必要がある。

まとめ

 協力要素は、ついその「快適さ」「参加のしやすさ」「楽しさ」といったものを追求しがちで、もちろん重要なのだが、それらはあくまでインフラであって「離れる要因を作らない」ことが主軸となる。
 「やる、やりたい」という「集まる要因」はもっと現金でシビアな部分であることを忘れると、いくらやり易くてもやらないので、注意する必要があるだろう。

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

0

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

今回はsedのお話。findも最後に組み合わせます。

はじめに

前回の記事からパラメータ加工について調べてみたり、いじってみたり。
※利用しているOSによってはバックスラッシュをつける文字があります。

sedで取り出し

正規表現で抽出して置換したり削除したりできます。

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

# 置換で擬似削除
$ grep "<page>" something.xml | sed -e "s/<[^<>]+>//g"

# 置換で抽出
$ grep "<page>" something.xml | sed -e "s/^.*>\([^<>]+\)<.*$/\1/g"

いずれも結果は30

s/{検索する正規表現}/{置換後}/{gをつけると検索対象全てに反映}

1つ目はタグ部分を削除する書き方です。 grep で該当行を抽出し、その行についてタグ部分を削除(値なしへ置換)しています。
sed の部分を sed -e "/<[^<>]+>/d" とすると、その行自体が削除されてしまい、抽出されません。

2つ目はパラメータが > と < に挟まれていることを利用した書き方です。ただ、これだとタグが1行に複数存在すると対応できませんので、その場合は grepで検索したパラメータを置換条件に含めます。

something.xml内
<title>DoRuby</title><page>30</page><pageTitle>What is DoRuby?</pageTitle>

# 〆る用のタグは検索しなくても良い(.*$ に全て含まれる)
$ grep "<page>" something.xml | sed -e 's/^.*<page>\([^<>]\+\).*$/\1/g'
結果:30

() はエスケープ必須。\1 は () で括られたマッチ部分を返します。() を複数使うと \2 以降も使用可能です。(詳しくは正規表現について調べてみてください。)

最後を </page> にする場合はエスケープ必須なため、 <\/page> となります。他のタグも紛れてしまう可能性がありそうですが、内部の値を取るために [^<>] で除外しているため、置換後の値にタグは入ってきません。
本記事はパラメータを取得する前提で話を進めていますが、もしタグを含む値や、 <>を含む値を取る場合は

$ grep "<page>" something.xml | sed -e 's/^.*<page>\(.*\)<\/page>.*$/\1/g'

となります。
またパラメータの検索で、抽出する部分以外の記載( ^.* 、 .*$ )もしていますが、これは前後の不要な部分も置換しなければそのまま残ってしまうためです。もしつけない場合は以下のようになります。

$ grep "<page>" something.xml | sed -e 's/<page>\(.*\)<\/page>/\1/g'

結果
<title>DoRuby</title>30<pageTitle>What is DoRuby?</pageTitle>

<page>タグのみ削除され、残りはそのまま残ってしまいました。

ファイル名リストを取得して全検索

複数ファイル指定をする場合は、他のファイルにあらかじめまとめておくか、シェルの配列を用意すると言った方法があります。

ファイルに記載しておく場合

>settings.txt内
something.xml
something2.xml
something3.xml

>something.xml内
<title>DoRuby</title><page>30</page><pageTitle>What is DoRuby?</pageTitle>

>something2.xml内
<pagea>something2-500</page>

>something3.xml内
<page>something3-100</page>
<page>something3-200</page>

# findで特定のファイル群を取得して行う場合はcatの部分のみ書き換えr
$ cat settings.txt | xargs grep "<page>" | sed -e 's/^.*<page>\(.*\)<\/page>.*$/\1/g'

結果 # something2.xmlはpageaになっているため取得しない
30
something3-100
something3-200

xargs で左側のコマンド処理の結果を引数として受け取ります。(つけない場合は左側のコマンド結果に対して grep します)
find を利用したファイル名取得にもそのまま応用できます。

# *.xmlで実行できない場合は"*.xml"
$ find ./ -name *.xml | xargs grep "<page>" | sed -e 's/^.*<page>\(.*\)<\/page>.*$/\1/g'
または
$ ls *.xml | xargs grep "<page>" | sed -e 's/^.*<page>\(.*\)<\/page>.*$/\1/g'

結果
30
something3-100
something3-200

シェルスクリプトの場合

#!/bin/bash
set -eu
array=("something.xml" "something2.xml" "something3.xml")
grep "<page>" ${array[@]} | sed -e 's/^.*<page>\(.*\)<\/page>.*$/\1/g'

ubuntuだとshのシンボリックリンクの初期値が dash になっているため、変更していない場合は配列型が利用できませんので実行に注意してください。(実行権限が付与されている場合はシェルスクリプト名で実行できます。付与していない場合は bash {シェルスクリプト名} )

おわりに

sedで簡単な置換は作ったことがありますが、そもそも正規表現使えるよねってことで、ちょっとだけ複雑な探索と置換を紹介しました。マッチした場所以外は出てこないようなコマンドがあればいいのですが、あることに気づいていないだけかもしれませんね。(そもそもこういう使い方を想定しているのか、という話ですが)
awkだと区切り文字の指定なのですよね…その代わりに制御しやすいのではという印象を受けました。


参考:
grepとawkで値検索

第10回「最近はやりのオープンワールドの魅力とは!?」

0

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

第10回「最近はやりのオープンワールドの魅力とは!?」について話していきたいと思います。

みなさん!こんにちは!Lionです。
前回の記事いかがだったでしょうか?
「就活の時にやっちゃいけない3つの事柄」というのが少しでも役に立ちましたら、嬉しいです!
さて、本日は「最近はやりのオープンワールドの魅力とは!?」について話させていただきます。

オープンワールドって何?

最近のゲームで、「オープンワールド」という言葉をよく聞きますね!
では、オープンワールドって他のゲームと何が違うのだろうか?
その違いを一言で表すなら「広大な世界を自分が好きなように行きたいところに自由に行動できる世界」のことです。
ステージがあって、それをクリアしたら違うステージを選択できるシステムとは違い、やりたいところからどんどんゲームを進めることができるというのが大きな利点です。
※最近出たゲームを参考に出させていただきますと、「ゼルダの伝説 ブレス オブ ザ ワイルド」が最たるものですね!

オープンワールドの魅力

オープンワールドは、他のゲームにはない楽しい遊び方や体験が沢山あります。
全部紹介しているときりがないので、3つほどご紹介します。

①遊び方は無限大!人の数だけ行動が変わる!
特にこれといって決められたルートなどはありません。
例えば昔ながらのRPGみたいに1本道のストーリーを進めるのではなく、気になったっところからどんどんクリアすることができる!というのがオープンワールドです。
「自分が倒しやすいボスから倒す」、「近くにある山や洞窟が気になるからダンジョンそっちのけで調査」、「敵が沢山いるけど無視しようか全部倒そうか」など自分の考えた遊び方で遊ぶことができます!

②圧倒的な没入感!
やはり、我々の現実世界と同じで、天気であったり昼夜があったり、家具や機械(ゲームによりけり)があったりと、まるで、自分がゲームの世界で本当に住んでいるんじゃないか?と思わせてくれます。
建築や物の作成システムなんてあったら一日中遊んでしまいますね。

③景色を見るだけで楽しい
壮大な景色が目の前で繰り広げられるのもオープンワールドの醍醐味の一つですね。
最近のオープンワールドでは、基本的に朝、昼、晩や天候や四季もあったりします。
同じ場所でずーっと立っていても風景が時間の流れとともに変化していくのは存外楽しいものです。
特に高いところから見た景色の移り変わりや天候の変化などはとても面白いです。

ここまで話してみて

いかがだったでしょうか?
オープンワールドの魅力が少しでも伝わればいいなぁと思います。では、次回の記事は、オープンワールドつながりで今絶賛大流行中のモンスターワールドの一部の機能について話していきたいと思います。
第11回「モンスターハンターワールドの痕跡集めについて 」を書いていきたいと思います。
最近、モンスターを狩猟しすぎて寝不足気味ではありますが、みなさんも気を付けて夜遅くまでゲームしないようにね(´・ω・`)ノ

第11回「モンスターハンターワールドの痕跡集めについて」

0

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

第11回「モンスターハンターワールドの痕跡集めについて」について話していきたいと思います。

みなさん!こんにちは!Lionです。
前回の記事いかがだったでしょうか?
「最近はやりのオープンワールドの魅力とは!?」という記事で、少しでもオープンワールドに興味を持っていただければ幸いです。
さて、本日は「モンスターハンターワールドの痕跡集めについて」を話させていただきます。
実はこの痕跡集め、今回のモンスターハンターワールドの機能の中で大事になってくる部分になります。
では、この痕跡集めについて色々分析してみたいと思います。

モンスターハンターワールドとは?

「痕跡」の話をする前にモンスターハンターワールドがどういうゲームか概要を書かせていただきます。
全世界で750万本も売れたゲームとして超話題なモンスターハンターワールドですが、実際はどんなゲームなのでしょうか?
公式のゲーム説明文をそのままのせると
「プレイヤーはハンターとなって、さまざまな環境に生息するモンスターを狩猟する、クエストを受注します。
モンスターを狩猟して手に入る素材を用いて、より強い武器や防具を作り、さらに強力なモンスターに挑むのです。
シリーズ最新作となる『モンスターハンター:ワールド』では、新たに構築された多種多様な地形や生態系が息づく世界で、究極の狩猟生活が体験できます。」

と記載されてました。
要するに広大なフィールドで様々なモンスターを倒して生活する狩猟ライフゲームですね!

ゲームをより面白くする痕跡集めのロジック

        enter image description here
では、さっそく新要素である「痕跡」集めについて話していきます。
まず、痕跡集めって何?って方に簡単に説明しますと、モンスターがその場所にいた跡の事を指します。
痕跡には地面にある足跡と木や岩にある爪痕の2種類が存在すし、ものにもよりますが、モンスターの落書きなどもあります。
モンスターの種族によって、痕跡も多種多様にあるということですね。

ゲーム内で痕跡を集めないとお目当てのモンスターに会うことができない。という内容になっています。
要するに、今までのモンハンの流れである、クエスト受注→指定されたモンスターを倒すに新たにクエストを受注(またはフリー探索)→痕跡集める→お目当てのモンスターがクエストにて出現という流れに変わりました。

これはオープンワールドを最大限楽しんでもらうためのロジックだと私は思います。
前回の記事で話しましたが、オープンワールドは如何にユーザーに自分がゲーム内の世界にいる!と思わせることが大事になってきます。
この痕跡集めというのは、モンスター達がオープンワールド内で生きているという感じを出すというところでとても重要なシステムなんです!
これにより、ユーザーはその生態系のヒエラルキーを楽しむことだってできます。
※でかいモンスターの縄張りには小さなモンスターの痕跡が無かったりなどなど

しかし、広大なオープンワールドでモンスターの痕跡を集めるのはとても困難です。
そこでもう一つのギミックである導蟲というシステムについてお話します。

ゲームを快適に進行させるためのギミック

導蟲とは、フィールドでモンスターの痕跡が近くあるとその痕跡の場所を示してくれたり、ある程度、痕跡が集まったら導蟲が痕跡の主であるモンスターまで案内してくれるようになるといったものです。
クエストが始まったら、最初は痕跡を探す事が重要なのですが、痕跡を集めた後に肝心のモンスターと会えなければ意味がありません。
広いオープンワールドの中で自力でモンスターを探し出すのも一苦労なのですが、この導蟲のおかげで楽々モンスターがいる場所まで行けます。
このようにナビゲーションの役割を果たしている導蟲は、ユーザーに対してストレスを与えないように設計されている素晴らしいギミックだと思います。

ここまで話してみて

いかがだったでしょうか?
オープンワールドの良さを壊さず、ユーザーへのストレスも考えた設計になっている今作のモンハンワールドは、今年の神ゲーの筆頭候補だと思います。

さて、次回は番外編です。「筆者が物事を始めるときに気にする事柄」を書いていきたいと思います。
ぶっちゃけ、自分語がやりたいだけです(笑)
では、またねー(´・ω・`)ノシ

拡大テクスチャの4つのにじみ対処法

0

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

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

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

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

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

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

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

 上記で修正したテクスチャを取り込んでみます。すると中央の黄色とピンクが接触している部分で黄色がピンクの中に飛び出ています。
しかしテクスチャをみてもそれらしい色はみあたりません。
ここが難しいところで、Unity上で拡大した際、ゲーム画面上でもなめらかに表示されるよう更に画面表示処理がかかります。そのため少しの色味でも影響範囲が大きく、上記のように隣り合った色の範囲がお互いに狭いと色が侵食することがあります。
この場合はテクスチャの侵食している部分、とその付近をそれぞれ同系統の色で塗りつぶす必要があります。
enter image description here
例えば黄色が侵食しているのならば侵食範囲に濃い目のピンクを、接触している部分に中間色を。そのように修正データを作成しては組み込み、侵食がどの程度消えるかを繰り返し確認していきます。1ピクセル・僅かな色の違いで影響範囲が大きいため都度確認し地道に潰していきます。

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

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

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

 ①のように中間色の線も潰し、③のように同色で塗りつぶしたとしても場合によっては中には図のように間の線をこして隣の色に広範囲に侵食する場合があります。
こちらの対処法は2点。
一つは、間の線を面にすること。間の色の範囲を大きくすることで侵食を消すことができます。
間の色に侵食するだけじゃないの?とも思いますが案外大きくした間の色には同じような色の侵食は発生しません。
もう一つは、色の系統を統一させてしまうこと。青をメインに使いたいならば寒色系と色を統一など、系統を統一させることで④のような侵食を防ぐことができます。
enter image description here
 どちらもデザインを変える最終手段ではありますが、イラストを作成中に事前に組み込んで問題ないかを確認していけば早い段階で手が打てますね。

最後に

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

クリックをトリガーに$.ajaxで外部htmlを読み込んだり削除したりする

0

この記事はアピリッツの技術ブログ「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ファイルを再読み込みするのは良くない。

データポータルの計算フィールドUIが変更

0

この記事はアピリッツの技術ブログ「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

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

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

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

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

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

これすごい便利ですよね。何が便利かって、作成途中のエラーに気づきやすいところがすごい。
あとは、他の人が計算フィールド見た時にどんな数式になっているか一目でわかるところが神です。
先ほどの「アルファベット」のコード、このUIなら僕はこう書きます。
enter image description here
あぁ、勢い余ってj行まで書いてしまいました。
インデントのためにスペースやタブを使っても数式エラーにならないところが最高ですね。

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

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

便利機能3:数式が長くなっても重くならない(気がする)

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

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

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

データスタジオの計算フィールドUIが変更

0

この記事はアピリッツの技術ブログ「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

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

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

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

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

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

これすごい便利ですよね。何が便利かって、作成途中のエラーに気づきやすいところがすごい。
あとは、他の人が計算フィールド見た時にどんな数式になっているか一目でわかるところが神です。
先ほどの「アルファベット」のコード、このUIなら僕はこう書きます。
enter image description here
あぁ、勢い余ってj行まで書いてしまいました。
インデントのためにスペースやタブを使っても数式エラーにならないところが最高ですね。

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

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

便利機能3:数式が長くなっても重くならない(気がする)

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

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

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

Sourcetreeを使ってみた件

0

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

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

CUIとGUI

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

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

GUIで扱うGit

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

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

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

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

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

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

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

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

おわりに

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

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

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

最近人気な記事