ホーム ブログ ページ 22

取り込んだ素材を自然に見せる方法

0

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

はじめに

近年たくさんの素材サイトがありとても便利です。
柄などの素材をイラストに取り入れた際どう見えるのか
柄が浮いてしまったり、線画が素材に負けてしまうのを自然に見せるやり方をご紹介します。

※Photoshopを使用しています。
素材はURLのフリー素材のサイトから使用しています。
・がま口テクスチャ:http://bg-patterns.com/
・柄テクスチャ: http://frame-illust.com/

線画に素材を加えます。
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
柄を複製してチェック柄に変えることもできます。
enter image description here

さいごに

今回はフリー素材を使用し個人的な方法をご紹介しましたが、仕事の場は各現場のルールがあると思いますのでそれに合わせていきましょう。

ボキャブラリーを増やすコツ

0

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

ボキャブラリーとは何か

ボキャブラリーとは、日本語に訳すと「語彙(ごい)」という意味です。
語彙とは、簡単に言うと「世の中に存在する言葉全て」です。
「ボキャブラリーが乏しい」というのは、「知っている単語」又は「使える単語」が乏しいという意味になる。

【引用】カタカナ語の意味まとめ

ボキャブラリーは自分の意見や考えていることを伝えるために必要になります。
今回はボキャブラリーを増やす方法をご紹介します。

読書

一番わかりやすく手っ取り早い方法です。
最初は自分の興味のあるジャンルからはじめて
徐々に幅を広げていけば
今まで知らなかった言い回しを見つけたり、
間違って覚えていた、使っていた言葉の正しい使い方を確認することができます。
結果としてボキャブラリーは増えているはずです。

インプットするだけでなく、
調べたこと、知ったことをまとめることで
アウトプットもできるとより身に付くのではないでしょうか。

調べる癖をつける

普段、自分の頭の中で考えられることは基本的に
自分が知っている言葉の中で行われています。

知らないことは当然思考には入りません。
知らない分だけ思考に制限がかかってしまうのです。

知らない言葉や気になる言葉を見つけたときはボキャブラリーを増やすチャンス!
すぐに調べましょう!
いまはスマートフォンで簡単に調べることができるのでそこまで手間ではありません。

後回しにすると大抵の場合、調べないままほったらかしになります。

「やばい」禁止

「やばい」という言葉は様々な状況で使えてしまうため
便利である一方、正確な意味が伝わりづらいです。


・このお店、雰囲気やばくない?
・このゲーム、難易度やばい!

良いとも悪いともとれる、その場のテンションなどでなんとなく意味は
推し量れますがあくまで推測に過ぎません。

自分の意見、考えを正確に伝えたい場合は避けるべきでしょう。

まとめ

・読書
・調べる癖をつける
・「やばい」禁止

以上、ボキャブラリーを増やす方法をご紹介しました。
ボキャブラリーを増やしたいと思っている方は意識してみてはいかがでしょうか。

極・メカニカルキーボード生活

0

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

最近購入したメカニカルキーボードが良い意味で変態的な仕様でしたのでご紹介したいと思います。

フルサイズキーボードとテンキーレスキーボード

フルサイズキーボードとは、テンキーが付いている標準的なキーボードのことで、日本語配列では108キーあります。
横に長いためスペースを取りますが、数字の入力がスムーズに行えるため、表計算ソフト等で数値入力を頻繁に行う人には向いています。

テンキーレスキーボードとは、その名前の通りテンキーがないキーボードのことです。日本語配列では91キーあります。
フルサイズキーボードに比べデスク上でのスペースを削減できるため、自分の好みのポジションに動かしやすいという利点がありますが、数値入力を頻繁に行う方にはあまり向いていません。

40%サイズキーボード

最近私は「Vortex Core」というキーボードを購入し、オフィスで使用しています。
画像検索すると分かりますが、とても小さいキーボードなので持ち運びに便利です。
vortex core – Google 検索
数字キーやファンクションキーは廃され、矢印キーすらなくなっています。
その大きさは248 x 76.2 x 25.5mmというサイズです。iPhone7 Plusのサイズが158.2 x 77.9 x 7.3 mmですので、幅についてはこのキーボードのほうが小さいということが分かります。

ここまで小さいと使いづらくないのか、と皆さんお思いになるでしょうが、その通り使いづらいです。

非常に使いづらいです。

このキーボードには「Fnキー」と「Fn1キー」があり、それらと他のキーの組み合わせで数字を入力したり矢印キーを使うことになります。
慣れればどうということはないと思いますが、慣れるまでに時間がかかります。

ですが、本体はとてもシンプルな作りで持ち運びもしやすいため、Macbookと一緒にオシャレな喫茶店で広げればドヤれるかもしれませんね。
ちなみにこのキーボードはWin版しかないため、Macでご利用いただく場合は各々工夫が必要となります。

おわりに

世の中にはさらに特殊なキーボードもありますが、小ささを求めるとこのキーボードに行きつくのかもしれません。
皆さんもキーボー道を極めていきましょう。

OGPを設定してFacebookシェアで目立たせよう!

0

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

OGPで画像を設定してシェア時に目立たせる様な対応を行ったのでそれについて記事にします。

はじめに

連続投稿となります。待ちに待ったプロ野球が開幕してテンション高めのむらさきです。
今回はFacebook等SNSでのシェアでたくさんの人の目に留まるように画像やタイトル等を設定するOGPについて書いていきたいと思います。

OGPとは

OGPとはOpen Graph Protocolの略です。FacebookなどのSNSにウェブページの情報を載せる際に必要なタグのことです。
OGPを設定することで下図のようにシェア時に任意の画像やタイトルを入れることができます!
enter image description here
画像を入れることで多くの人の目に留まるようになりたくさんの人に見てもらえる機会が増えるので是非設定しましょう!

OGPの設定方法

OGPは設定したいページのhead内に以下のようなmetaタグを入れることで設定できます。

<meta property="og:locale" content="ja_JP">
<meta property="og:site_name" context="DoRuby">
<meta property="og:title" context="RailsでLoggerを使ってLogローテーション">
<meta property="og:description" context="DoRubyは、株式会社Appirits(アピリッツ)が運営するWeb技術・マーケティング情報発信ブログです。Ruby on Railsを中心に開発現場ならではの実践的な情報を随時掲載していきます。">
<meta property="og:type" context="article">
<meta property="og:url" context="https://doruby.jp/users/ueki/entries/Rails%E3%81%A7Logger%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6Log%E3%83%AD%E3%83%BC%E3%83%86%E3%82%B7%E3%83%A7%E3%83%B3">
<meta property="og:image" context="https://doruby.jp/images/doruby_og.png">

今回はこのように設定しました。
OGPには必須で入れないといけないものが4つあります。

og:title    ページのタイトル
og:type     どんなページなのか(今回は記事のページなのでarticleを設定しました。blogやwebsiteなどもあります。)
og:url      ページのurl
og:image     ページの画像

です。それ以外に書かれているmetaタグは必須ではないですが入れることでより詳しく表示させることができます。

og:description     ページの説明文
og:locale         サポートしている言語
og:site_name       サイトの名前

となっています。自分のページに合わせて設定しましょう!

OGPの確認

OGPが正しく設定されているかを確認するにはfacebook for developersのシェアデバッガーを使用しましょう。
ここに確認したいページのurlを入れることで正しく設定されているかを確認できます。
また、設定してもfacebookのクローラーにクロールされないと設定した画像等には切り替わらないのですが、「もう一度スクレイピング」を押すことですぐに設定した情報を反映させることができます。

おわりに

いかがだったでしょうか。
OGPを設定して画像を変えたのに変わっていない!?と焦りましたが、シェアデバッガーで確認と同時に更新が出来るのでクロールされるのを待つ必要がないのはとてもいいですね。
OGPを正しく設定してたくさんの人の目に留まるサイト作りを目指しましょう!

変数命名:ハンガリアン記法について

0

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

皆さんはどのように変数名を決めているでしょうか。
命名規則がしっかり決まっているようであればそれに合わせれば良いのでしょうが、
複数人でプログラムしている場合、同じ単語を使っていても違った使い方をされる変数だったりすることがあります。
そんなことが自分自身にもありましたので命名規則の内の一つ、ハンガリアン記法について書いていきます。


ハンガリアン記法とは?


キャメルケース、スネークケースなどの単語と単語のつなげ方を意味するものではなく、
変数の意味や用途をわかやすくするために情報つけて命名するもので、以下の二つのものがあります。

  • アプリケーションハンガリアン
  • システムハンガリアン

アプリケーションハンガリアン


変数名にその変数の情報をつけてぱっと見で間違いを分かりやすくする方式です。
例えば何かの座標を入れる変数名に
positionX
positionY
と命名するのではなく、
absPositionX
relPositionY
といったように絶対座標なのか相対座標なのかといった情報を付け加えるといった感じです。
そうすることによって書かれたコードが間違いであることを分かりやすくします。

Player.posX = absPositionX;
Player.posY = relPositionY;

上記のような代入がされていたら誰でも疑問を抱くと思います。
アプリケーションハンガリアンなんて知らなくても、用途を分かりやすくしようと
変数名をつけるときにこのような形にしている人もいるんではないでしょうか。


システムハンガリアン


ハンガリアン記法といったらこっちのイメージが強いです。
変数名の頭などにその変数の型やスコープなどの情報となる文字をつける方式です。

一般的な例を以下の表にまとめました。

型,スコープなど追加文字使用例
論理型bbEnable
整数型nnCount
浮動小数型ffAngle
文字列ssDescription
ポインタppParent
グローバル変数g_g_pManager
クラスCCManager
クラス内のメンバ変数m_m_nCount

デメリット

  • システムハンガリアンで変数名をつけていた場合、途中から変数の型を変更しようとした場合多くの手間がかかる。
  • 型を変数名につけてしまっているので、変数名の変更忘れなどがあると無駄にソースが分かりにくくなってしまう。
  • 移植性が悪くなる。

おわりに


個人的にシステムハンガリアンに関しては型宣言を必要とするc++やc#においては全く必要がないかと思います。
コンパイル時点でエラーや警告でわかる場合が多いですし。

ですが型宣言を必要としないrubyなどの言語ではシステムハンガリアンで記述してもいいなと思いました。
変数にいろんな型のデータを代入できるがゆえに、何を入れるための変数なのか、何が入っている変数なのか役割をしっかり定義しておいたほうがいいと思います。

17新卒投稿記事ランキング!

0

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

新卒研修合宿でDoruby月1投稿を決めてから約10ヵ月。 ゴールに設定していた3月までの投稿が一通り終わったということで、新卒の「記事投稿数」「記事view数」「累計view数」をランキング形式で振り返ってみたいと思います。

記事右下のview数は同じ人の複数閲覧はカウントされておらず、社内IPの閲覧もカウントしているためssekiさんがこのプロジェクト開始時に作成してくれたデータスタジオの集計データを使用していきます。
データは2018/3/29 17:35のものを使用しています。

記事投稿数TOP3!!

第3位 11記事!

第3位は11記事を書いたHelloWorld?さんです
文章が独特で内容についての知識がなくてもついつい最後まで読んでしまう…そんな記事が多い印象でした。
記事画像が毎回食べ物関連なのは謎です。

第2位 13記事!!

第2位は13記事を書いたssekiさんです
彼の記事はデータスタジオについてのみで13記事書かれています。
流石アナリスト、記事もとてもきれいに書かれていてデータスタジオについて全く知らなくても使いこなせる気になってきます。

第1位 16記事!!!

第1位は驚異の16記事を書いたLionさんです!
内容はゲームレビューやライフハック自身の経験談など様々でとても面白い記事が沢山ありますので見たことがない人はぜひご覧ください!

記事view数TOP3!!

第3位 AWSでRedashを使ってみる 1,540view

記事view数第3位はくじらさんのRedashがAWSで使えるようになる方法をまとめた記事でした!

第2位 ExcelでSQL文を発行する〜INSERT文〜 2,672view

第2位はknagataさんのExcelでINSERT文を発行する方法を示した記事でした。

第1位 立ち絵を魅力的に描く①【ポーズと表情でキャラクターを伝える】 9,078view

第1位は断トツの9000view越え、nocoさんの立ち絵の書き方のポイントを共有した記事でした!
pixiv等でも参考にして書いてみたなどで使われておりたくさんの人に見てもらえている記事になってます!

累計記事view数TOP3!

第3位 くじら 4,194view

第3位はActiveRecordやUnityなどについての記事が多かった くじらさんです!

第2位 inoooooocchi 4,659view

C#やUnityについての記事が多かったinoooooocchiさんが第2位にランクイン!
Unity関連の記事は検索されやすい傾向にありそうですね!

第1位 noco 11,329view

記事view数で断トツの1位を取ったnocoさんが累計記事view数でも1位でした!
かわいい絵がたくさんなのでさっきからこれしか言ってませんが是非ご覧ください!

累計記事view数はすべてアピゲー部(弊社の自社開発ゲーム部署名)の社員が総取りでした!

おわりに

いかがだったでしょうか。
17新卒で決めたDoRuby投稿が3月で終わり、気づいたらもう4月。1年間がとてもあっという間でした。
自分で投稿した記事のview数が伸びてるか確認するのが毎日のちょっとした楽しみでした。
記事を投稿することで自分の取り組んだタスクの復習にもなりとても勉強になりました。
17新卒が投稿する頻度は落ちるかと思いますが17新卒の記事かな?っていうのを見かけたら覗いてもらえると嬉しいです。

fugitive.vimでvim上でgit操作をしよう!

0

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

fugitive.vimプラグインを使うとvimでファイルの編集をしながらgitの操作ができます。
前回コミットとの差分の表示などを簡単に表示できるのでとっても便利です。

導入

dein.vimを使っているので.vimrcに以下を追記

  call dein#add('tpope/vim-fugitive')

 
これでvim上のコマンドでgitの操作が可能になります。
 


主なコマンド


:Gstatus

git statusが上部に表示される。
enter image description here

statusの確認だけでなく、
表示されているstatusのファイル名にカーソルを合わせてキーを打つことで動作を行える。

Dvimdiffで直前のコミットとの差分を表示
addとresetを切り替え
Enterファイルを表示

:Gdiff

vimdiffで直前のコミットとの差分を表示する。
自分はこれを一番多用してます。

enter image description here

:Gread

開いているファイルを直前のコミットの状態でみる。
 

:Gwrite

開いているファイルをgit addする。
 

:Gremove

開いているファイルをgit rmする。
 

:Gblame

開いているファイルをgit blameする。
見ていた行から表示してくれるので便利です。
普通のgit blameとは違いvimの設定の色がついてくれるので見やすいですが少し重いです。


かなり便利なので使ったことない人は一度使ってみてはいかがでしょうか。

github: https://github.com/tpope/vim-fugitive

source_locationでRubyを冒険

0

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

rubyのMethodやProcにはsource_locationというメソッドがあります。これを使うことでゴーストメソッドでも定義場所を発見できRubyコードの探索を簡単に行うことができます。

はじめに

新卒最終日になりました。くろすです。
今回はメソッド探索に使うと便利な Method#source_location, Proc#source_location の紹介をします。

Method Class

メソッドクラスは Object#methodによりオブジェクト化する際に使われるクラスです。
詳しいことはだいたいドキュメントに書いてありますが、Procオブジェクトと違いレシーバーの情報も持っていて、クロージャーではないというのが大きな特徴です。
すでに定義してあるメソッドをオブジェクトとして取ってこれるという点で便利だなと思います。

https://docs.ruby-lang.org/ja/latest/class/Method.html

source_location

さてそんなMethodClassの source_location ですが、色々話すより見てもらう方が早いと思います。

[1] pry(main)> ActiveRecord::Base.methods.grep(/transaction/)
=> [:transaction]
[2] pry(main)> ActiveRecord::Base.method(:transaction)
=> #<Method: Class(ActiveRecord::Transactions::ClassMethods)#transaction>
[3] pry(main)> ActiveRecord::Base.method(:transaction).source_location
=> ["path/to/gems/activerecord-4.1.15/lib/active_record/transactions.rb", 206]

使ってるgemが古いのは置いといてgemの中でもrubyで定義してあれば探すことができます。

[1] pry(main)> class Ghost
[1] pry(main)*   (1..3).each{|n| define_method("method_#{n}"){ puts n } }
[1] pry(main)* end
=> 1..3
[2] pry(main)> g = Ghost.new
=> #<Ghost:0x007f99da931d38>
[3] pry(main)> g.method_1
1
=> nil
[4] pry(main)> g.method(:method_1).source_location
=> ["(pry)", 2]

ご覧の通りdefine_methodでも余裕です。
が、method_missingを利用したゴーストメソッドはさすがに追い切れないです。

[1] pry(main)> Hash.method(:new).source_location
=> nil

ruby外で定義されているメソッドは残念ながら探せません。

終わりに

ぶっちゃけると define_method 対策として紹介しているので、define_methodを使わないようなコードではあまり使いどころがないと思います。
僕自身は開発にneovimを使うのでコードジャンプできなかった場合、ターミナルエミュレータを起動、highway、rails consoleからのsouce_location の順番でメソッドを探しています。
プログラムを読むために検索するというのは日常的なことだと思うのでその検索が少しでも早くなる手助けになればと思います。

社内ブログを書くことで得られた3つのこと

0

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

今回は社内ブログを書くことで得られたメリットをご紹介します。

①新たな知識が身に付く

記事としてまとめるために、自分の中の知識だけでは不安があります。
そのため、間違った理解をしていないか、なるべく多くの情報を集めます。

情報を集める中で
いままで気付けなかったことに気付くことができたり、
実際に記事には書いていなくても新たな知識として蓄積されます。

②思考力がつく

①で身に付けた知識や日々の仕事で学んだことをまとめることで
一度自分の思考が整理されます。
ごちゃごちゃしていた頭の中を整理することでより深く考えられるようになります。

アウトプットする機会は意識しないと意外と少ないもので、
その機会を得られるのは社内ブログを書くことの大きなメリットだと思います。

③文章を書く練習になる

文章を書くのは正直苦手でしたが10記事書く頃には大分抵抗も減りました。

当たり前ですが書かないと一生書けるようにはなりません。
まずは書く。書く習慣を持つキッカケになりました。

まとめ

①新たな知識が身に付く
②思考力がつく
③文章を書く練習になる

以上、社内ブログを書くことで得られる3つのことをご紹介しました。
社内ブログでなくとも何かを発信することは自分にとって大きなプラスになるはずです!

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

オフィスで簡単!ストレス解消方法!

0

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

今回はストレスをため過ぎないようオフィスで簡単にできるストレス解消方法をご紹介します。

ストレスとは

外部から刺激を受けたときに生じる緊張状態のこと。

外部からの刺激には、
天候や騒音など環境的要因や、睡眠不足などの身体的要因、
不安や悩みなどの心理的要因、人間関係が上手くいかない、
仕事のノルマや締め切りに追われてるなどの社会的要因があります。
日常的に起こる色々な出来事がストレスの要因になってしまうのです。

ストレスはためすぎると体調を崩したり、気持ちが不安定になったり、
さらには心の病気にもなってしまうこともあります。

【引用】厚生労働省:知ることからはじめよう、みんなのメンタルヘルス

今回はストレスをため過ぎないようオフィスで簡単にできるストレス解消方法をご紹介します。

こまめに席を立つ

ずっと同じ姿勢というのは体にもよくありません。
またそもそも集中力は長時間持たないので適度な休息が大切です。

トイレにいったり、軽くストレッチをしたり、何でも良いので席から立ちあがりましょう。
他の人の仕事の邪魔にならない程度であれば、誰かとお話するのも良いと思います。

ガムを噛む

噛むという行為が脳への血流を良くするため、
不安な気持ちを落ち着かせ、前向きな気持ちになれる効果があるそうです。

ストレス解消に役立つ食べ物でダークチョコレートも有名ですが、
チョコレートは太ってしまうんじゃないか…
という不安が新たなストレスに繋がってしまう可能性も。
その点、ガムであれば低カロリーなので安心です。

5年や10年後も忘れない出来事か自答する

仕事の中には嫌なことも理不尽なこともあると思います。
心が折れてしまいそうな出来事であっても一度冷静に、5年10年後、忘れられないようなことか
考えてみましょう。
大抵のことは忘れることができる、それほど重要なことではないはずです。

まとめ

・こまめに席を立つ
・ガムを噛む
・5年や10年後も忘れない出来事か自答する

以上、オフィスで簡単にできるストレス解消方法をご紹介しました。
どれも簡単に出来ることだと思うのでストレスが気になる方はぜひお試しください。

有料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のクラフト機能について分析」という内容を記事にして書いていきたいと思います。
ではでは、またねー(´・ω・`)ノシ

最近人気な記事