Pon De Beach

叩こう ココナッツ アゴゴ

株式会社はてなに入社しました

株式会社はてなに入社しました

株式会社はてなに入社しました - hitode909の日記

beatmania IIDX はたのしい

この記事は #音ゲーマー達の発信所 (1枚目) Advent Calendar 2016 9日目の記事です。

ステータス

  • SP(Single Play)
  • 2P側
  • 対称固定(っぽい運指)
  • 三段
  • 週に3~4日は通っている

今は四段を取るべく奮闘しております。 R5の7軸が辛すぎる

ボタンをおすのがたのしい

物理ボタンの音ゲーは慣れるまでが難しいけど、慣れると楽しい。同時押しとか脳汁出るくらいたのしい。

☆5~6が出来るようになってきた辺りでたのしくなってくる

曲がたのしい

筐体があれだからクラブミュージックとかハードコアばかりかというとそうでもない。いろんなジャンルの曲がある。

『Innocent Walls』 が最高にかっこいい

やってから知ったけど、IIDXは音にフィルターをかけたりテンポを調整できるから色んな曲の楽しめ方がある。

段位モードがたのしい

基本つらいけど、クリアするとたのしい。初段をクリアするのにとても苦労した。 ワーン

筐体がでかくてたのしい

とにかくでかい。筐体がでかいから画面もでかいし音もでかい。たのしい

ムービーがたのしい

プレイに忙しくてムービーなんて見ていられないけどたのしい。かっこいいのもあるしかわいいのもある。

おすすめは『駅猫のワルツ』。猫がいっぱいでてくる。

まとめ

IIDXはたのしかった

明日は

kさんです!

Rails のアセットパイプライン(Asset Pipeline)について

アセットとアセットパイプライン

アセット(Asset)とは、 HTML ファイルに付随するCSS, JavaScript, 画像ファイルといった直接のレスポンスでないファイル を指します。

アセットパイプライン(Asset Pipeline)とは、 複数のアセットファイルをコンパイルし、1つのファイルに統合する ための仕組みのこと。複数あるアセットファイルを1つに統合することでクライアント側のリクエストを減らし、より素早いレスポンスを返すことができるといったメリットがあります。

Sprockets (Rails でアセットパイプライン機能を提供する gem) について

Rails におけるアセットパイプラインという仕組みは、 Sprockets と呼ばれる gem によって実現しています。

Sprockets は以下の機能を提供しています。

  1. アセットファイルにアクセスするためのパスを管理する
  2. アセットのコンパイル
  3. アセットファイル同士の依存性の管理

1つずつ詳細を見ていきます。

アセットファイルにアクセスするためのパスを管理する

様々なディレクトリに置かれているアセットファイルのパスを管理し、 仮想的に1つのディレクトリにまとめて置いてあるようにクライアント側に見せる機能 です。

Sprockets の最も基本的な機能です。

例えば、普段開発を行う上で CSS ファイルは /assets/stylesheets に、 JS ファイルは /assets/javascripts という感じでファイルの種類ごとに分けてアセットパスを管理すると思います。これらの異なるディレクトリ下で管理されているファイル群を /assets に仮想的にまとめることができ、/assets/main.css というようにアセットファイルを参照することができるようになります。

Rails におけるアセットファイルの置き場所

rails new をした時点であらかじめいくつかのアセットパスが用意されています。

  • app/assets …アプリケーションの主要な機能に関わるアセットファイル
  • lib/assets複数のアプリケーションで使われるような機能に関わるアセットファイル
  • vendor/assets …外部から取得したアセットファイル

CoC (設定より規約)に反しないためにも、適切な場所に適切なアセットファイルを置くように心がけましょう。

config/application.rb でアセットパスの追加ができます。

アセットのコンパイル

JS や CSS のアセットファイルを コンパイル してくれます。元々 JS, CSS のファイルは何も起きません。

Rails ではデフォルトで CoffeeScript, Sass をコンパイルします。

例えば、 hello.js.coffee といった拡張子が連なって記述されたようなファイルを Rails でみかけたことがあるとおもいます。 Sprockets では拡張子からファイルの種類を判別しコンパイルします。この場合は、 hello.js.coffee.coffee から CoffeeScript ファイルと判別しコンパイルして、最終的に生 JS ファイルとして出力されます。

この拡張子複数つけることも可能 です。

hello.js.coffee.erb というアセットファイルは、 ERB → CoffeeScript という順番でコンパイルを行い JS ファイルとして出力されます(後ろの方から順番にコンパイルが走る)。

コンパイルする種類は増やすことができます。

TypeScript を追加したい場合は、以下の方法で可能なようです。

Ruby on RailsでTypeScriptを使ってみよう! | nanapi TechBlog

アセットファイル同士の依存性の管理

アセットファイル同士で起こる依存関係を『マニフェストファイル』と呼ばれるファイルで管理することができます。依存関係というのは、例えば hoge.jsjQuery を使ってる…みたいなパターンです。hoge.jsjQuery の機能を使っているので、 jQuery がないと動かない、つまり依存関係にあるということです。

rails new した時に作られるマニフェストファイルは app/assets/javascripts/application.jsapp/assets/stylesheets/application.css になります。

実際に中身を見てもらうとわかりますが、 //=require jquery という記述があります。この記述がアセットファイル同士の依存性を管理している構文になります。コメント内で記述されているのはその他のツールで読み込んだ時に影響を与えないようにです。

require の部分は ディレクティブ と呼ばれ、 require 以外にも何種類かディレクティブがあります。その一部を紹介します。

ディレクティブ 説明
require 引数として与えられたファイルが自身よりも前に挿入される。2回目以降呼び出されても読み込まれない
include require と同じ動きをするが、2回目以降呼び出されると都度ファイルの内容が挿入される
require_directory 与えられたディレクトリ以下のファイルを、自身よりも前に挿入する。順番はアルファベット順(さらに大文字→小文字)になる
require_tree require=directory と同じ動きをするが、再帰的に読み込む

読み込みはコードの 上から順番に 読み込まれます。

Rails で生成したマニフェストファイルには //=require_tree . という記述があります。//=require_tree . はカレントディレクトリ以下の全てのファイルを再帰的に読み込んでいきます。自作したアセットファイルが自動で読み込まれるのは //=require_tree .マニフェストファイル内にデフォルトで書いてあるからですね。

開発環境において、マニフェストファイルが正常に読み込まれているかデバッグするためのヘルパーメソッドがあります(stylesheet_link_tag, javascript_link_tag)。これを利用することでマニフェストファイルで読み込まれた順にアセットファイルが記述されていることを確認できます。

また、 config/environments/development.rb 内で config.assets.debug=true と設定しなければなりません(デフォルトは true)。false の場合は本番環境と同じく1つのアセットファイルに纏められます。

アセットファイルのプリコンパイル

リクエストが来た時点で事前にコンパイルしたアセットファイルを渡すことができる機能です。

$ rake assets:precompile

というコマンドでアセットファイルのプリコンパイルを行なうことが出来ます*1

プリコンパイルを行なうことで、リクエストのたびにコンパイルをする手間が省けより効率的にレスポンスを返すことができるようになります。

Rails のデフォルトでプリコンパイルはしてくれますが、デプロイ時にプリコンパイルした静的ファイルを一緒にデプロイするのを忘れずに。

フィンガープリントについて

Sprockets でコンパイルされたアセットファイルは ファイル名-MD5 値.rb という形式のファイル名になります(例えば application.css のフィンガープリントは application-5eece9848f909164a45045f6a24bc6b1.css となる)。 MD5 値は元のファイルの内容から生成されたもので、これはファイルの更新があったかファイル名を参照するだけで済むというメリットがあります。

参考

書籍:パーフェクトRuby on Rails(p.94~104)

アセットパイプライン | Rails ガイド

*1:Rails 5 からは rake じゃなくて rails に統合されたんだっけ

universal-ctags で Vim からのコード参照を楽にする

備忘録

ちゃんと使えよって意味で

これはなに

関数やクラスの定義元にジャンプできるやつ。もともとは Vim に組み込まれていた機能だったが、バージョン6のリリースとともに独立したらしい。

正確に言うと universal-ctags とは、本家 ctags からフォークしたプロジェクトです。

Vim 以外のエディタでも ctags は使えます(Emacs, Sublime Text など)が、ここでは Vim についてのみ記述します。

作業環境

  • OS X El Capitan (10.11.4)
  • Vim (7.4.488)

インストール

GitHub リポジトリの README に記載されているやり方に従います。

github.com

github.com

$ brew tap universal-ctags/universal-ctags
$ brew install --HEAD universal-ctags

既に ctags を Homebrew からインストールしている場合は、アンインストールしておきます。

$ brew uninstall ctags

ctags でない理由

本家である ctags を使わない理由としては、2009年以降更新が途絶えているからです。

sourceforge.net

これでは最近生まれた言語(例えば Go 言語)では利用できないので、本家からフォークされた universal-ctags に移った次第です。

ここで回答している通り、 ~/.tags に書いても良いのですが、毎回これだと流石に辛いと思ったので……

universal-ctags は Go や Rust なんかをサポートしていますので良さがあるように見えます。

使い方

初めにプロジェクトのルートディレクトリで以下のコマンドを実行して tags ファイルを生成します。

$ ctags -R

-R オプションで再帰的にタグを生成しています。

git 管理下ではステージングファイルの候補一覧に表示されるので、 .gitignoretags を追加しておきましょう。

定義元にジャンプする

関数やクラスのインスタンスにカーソルを合わせて <C-]> を押下すると、定義元にジャンプします。定義元が別ファイルにある場合は新規バッファが開きます。元に戻る場合は <C-t> です。

画面分割する場合は、<C-w><C-]> するとよいです。

g<C-]> すると、候補が1つの場合はそのまま定義元へジャンプし、候補が複数の場合は候補一覧を表示してくれます。

TODO

tags ファイルは新しく関数を作ったりする度に $ ctags -R で更新する必要があるので、自動化する。更新のタイミングとしては :w で保存する時、 git commit する時などがよさ気。


参考:実践Vim 思考のスピードで編集しよう!(書籍)

実践Vim 思考のスピードで編集しよう!

実践Vim 思考のスピードで編集しよう!

【Splatoon】ギアパワーの調整で今後使われていくかもしれないギアの紹介

こんにちは、mizukmbです。

本日(2016/03/04)のニンテンドーダイレクト放送内にて、 Splatoon 更新データ配信の発表がありました。

ガチマッチの調整、既存のブキを改造した「ブキチセレクション」等これから夏に向けて順次配信予定とのことです。

その中から今回は ギアパワーの調整 についての説明と、今後、ガチマッチにおいて(もしかしたら)使われていくかもしれないギアを紹介したいと思います。

調整されたギアパワーたち

公式サイト内の情報によると、 2016/03/09 に配信される更新データにおいてギアパワーの調整がされるそうです。本記事執筆時が3月4日ですので、もうすぐですね。

どのギアパワーが調整されるのかはこちらを参照していただくとして、今回はその中から私が「ガチマッチで使えそう」と思ったギアパワーを紹介したいと思います。

逆転勝ちの可能性を高める『ラストスパート』

△ガチマッチでは、相手チームのカウントが30以下になった場合、それ以降継続して効果が発揮されるようにしました。

△ガチマッチでは、延長中も効果が発揮されるようにしました。

△これまでの効果に加えて、発動中は復活時間短縮の効果も発揮されるようにしました。

これまで、ナワバリバトル向きであり、ガチマッチだと全く役に立たなかったラストスパートがようやく実用性のあるギアとなりました。

ガチホコやガチエリアではのこり30以下になっても試合が続くことが多いので、恩恵を大きく受けられそうです。延長時間でも効果が持続するのは地味に嬉しいですね。

スペシャル増加量アップよりもいいかもしれない『逆境強化』

△発動中のスペシャルゲージ上昇速度を、これまでより20%速くしました。

やられた味方数だけスペシャルゲージの上昇速度が上がる『逆境強化』ですが、さらに性能が向上しました。やられないように耐え忍びつつスペシャルゲージを貯め、一気に優勢に持っていくという立ち回りができます。

スペシャル増加量アップ』とどちらが効率が良いか?という研究や検証が Twitter 等でされてますが、 劣勢時にスペシャルを使って逆転を狙えるブキ(.96ガロンデコ、ホッカス、ノヴァネオなど) は『逆境強化』の方が良いかもしれません。

スーパーセンサーの攻撃的な対策としての『うらみ』

△これまでの効果に加えて、相手にマーキングされている間、攻撃力アップ・防御力アップ・ヒト移動速度アップの効果が発揮されるようにしました。

リッター3kやダイナモ等のスーパーセンサー持ちが多くいる現環境では、対策として『マーキングガード』をつけることがほぼ必須でした。そのせいで、『うらみ』の効果が微妙になりナワバリ・ガチマッチ共にあまりみないマイナーなギアという立ち位置でした。

しかし、今回の調整により スーパーセンサーにおける攻撃的な対策 として使えるギアになりそうです。

とはいえ、潜伏メインのブキでは使いにくいのでブキとの相性を見ながらという感じになりそうですね。

こんなギアがあったのか『ボムサーチ』

△これまでの効果に加えて、スプラッシュボム・キューバンボム・チェイスボム・トラップの、100.0未満のダメージ(※)を40%軽減し、クイックボムのダメージを20%軽減するようにしました。

※攻撃力アップや防御力アップの効果を計算する前に判定します。

スプラトゥーンを始めてから半年以上が経ちますが、 ガチマッチでは一度も見たことがない 『ボムサーチ』がかなり防御的な調整がされました。

『安全シューズ』との選択となるので、使われるかは正直微妙なところではありますが、防御ガン積み等の場合は使えるかもしれません。

CoD:BO の Perk にある「フラッグジャケット」ぽくなりましたね。


今回紹介したギアは一部ではありますが、調整が入ったギアは全て強化されています。しかし、今回の更新で今の環境が変わるかと言われれば…うーんって感じです。(『攻撃力アップ』にシールド破壊時の威力増大くらいの調整が欲しかった)

今後は、既存ブキを改造した「ブキチセレクション」の配信もありますので、 Splatoon はまだまだ長く遊べそうですね!

スプラトゥーン イカすアートブック (ファミ通の攻略本)

スプラトゥーン イカすアートブック (ファミ通の攻略本)

DBpedia Japanese を利用して各プログラミング言語の関係性を可視化してみる(実践編)

f:id:mizukmb:20151209204231j:plain

この記事はFUNAdventCalendar2015 9日目の記事です。

前回の続きとして、実際に DBpedia Japanese からデータの取得 を行いたいと思います。本記事を読む前にご一読頂けると今回の内容についての理解がより深まると思います。

前回の記事

mizukmb.hatenablog.com

それでは始めます。

DBpedia Japanese からデータを取得するために

前回ご紹介した DBpedia JapaneseRDF データから求めるデータを取得するために SPARQL を利用します。

取得するデータについてですが、今回のテーマである プログラミング言語の関係性を可視化 のために 影響を受けた言語 を取得しようと思います。 RubyWikipediaページ(https://ja.wikipedia.org/wiki/Ruby) を確認すると infobox の項目に影響を受けた言語についての情報が掲載されていることが確認できます。

f:id:mizukmb:20151209205857p:plain

前回説明したとおり、 DBpedia Japanese では infobox の情報を RDF データに変換して持っていますので利用できそうなことが分かりました。

実際に SPARQL を利用してデータを取得してみようと思います。

Web 上で公開されている多くの LOD は データのアクセスポイントとして SPARQL EndPoint を持っています*1。ここに検索を問い合わせることで結果を得ることができます。

ちょっとやってみましょう。DBPedia Japanese の SPARQL EndPoint を見てみると、何か書かれてますね。 SPARQL は RDF の検索のために利用すること東京都 という文字があることから 東京都に関する情報を検索してくれそう と予想できます。とりあえず実行ボタンを押してみましょう。

どうですか。下の画像のような結果が出ていませんか?

f:id:mizukmb:20151209213100p:plain

無事 SPARQL を実行して結果を得られたようですね。おめでとうございます!👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏

ちなみにさっき実行した謎の文字列

select distinct * where { <http://ja.dbpedia.org/resource/東京都> ?p ?o . }

これはおおまかに言うと 「東京都を主語として持つ述語と目的語の組み合わせを全て取得して下さい」 という意味になります。もちろんもっと細かい意味などはありますが、今回は雰囲気を掴んで欲しいので割愛します。

…ですが、 RDF の重要な項目について説明していなかった部分があったので補足します。

RDF はトリプルという 主語(Subject)、述語(Predicate)、目的語(Object) の3要素の組み合わせによって構成されています。 これらの要素は URI(あるいは IRI)を使用することが定められています。但し、目的語に関しては単純な文字列や数値(リテラル)の使用が許されています。 URI を使用することで コンピュータが参照可能なメタデータ** として扱うことができます。

雑な説明でしたが、本題に戻ります。

プログラミング言語の関係性を可視化するぞ!!

今度こそ、各プログラミング言語の関係性を DBpedia Japanese から取得し可視化しようと思います。

前述のとおり、各プログラミング言語の関係性は 影響を受けた言語 をそれぞれのプログラミング言語から取得することで可視化していきます。

Ruby を例にすると

の主語と目的語群の組み合わせを取得します。ちなみに影響を受けた言語は必ずしも書かれているわけでは無いのであしからず。

そしてデータを取得するために利用する SPARQL クエリを予め用意致しました。

SELECT DISTINCT ?label ?influencedBy
WHERE {
  ?s rdf:type dbpedia-owl:ProgrammingLanguage;
  rdfs:label ?label.
  OPTIONAL {
      ?s dbpedia-owl:influencedBy ?ib.
      ?ib rdfs:label ?influencedBy.
  }.
}
ORDER BY ?label

こいつを先ほどの SPARQL EndPoint で実行することで結果を得ることができます。

f:id:mizukmb:20151209230924p:plain

どうですか。プログラミング言語の名前が沢山出てきたと思います。左側の言語が右側の言語の影響を受けているという風に読み取れます。


これで本来の目的である 『DBpedia Japanese を利用して各プログラミング言語の関係性を可視化してみる』 を果たすことができました。 LOD という仕組みはあまり知られてない上に利用する技術も多く大変です。ですが、 LOD 及びセマンティック Web がどういうものであるのかを今回の内容を通じて知っていただけたら私自身もアドベントカレンダーをやった甲斐があるというものです。

2回に渡る説明にこれまで付き合ってくださった皆様に多大なる感謝を申し上げると共に本記事を締めさせて頂きます。ありがとうございました。

付録: Graphviz を利用したデータビジュアライゼーション

今回の結果を更に見やすくするために、 Graphviz と呼ばれるグラフ作成ツールを使ったデータビジュアライゼーションを行いました。むしろここまでやって可視化といえるのでは。

使用言語は Python です。 Python から SPARQL クエリを利用するためにSPARQLWrapperを、 Graphviz を利用するためにPyGraphviz をインストールして下さい。

$ pip install SPARQLWrapper
$ pip install pygraphviz

そして下記コードを実行すると sample.pdf というファイルが生成されます。

gist913cc0156d328720cd8a

実際に生成されるファイルはこちらです。(画像がでかいのでリンクのみ)

グラフをどんどん辿れるのでこっちの方が可視化っぽいですね。

*1:持ってない場合もあります…

【小ネタ】GitHub の Gist などで画像を使用するために

メモ

GitHub Gist や README 等で画像を使用する場合はどこか別のサーバ(DropBox や imgur 等)にアップロードしなければなりません。

ですが、 issues ではドラッグドロップで画像を GitHub の画像サーバにアップロードできますので、あとは生成された URL を使えばおk。

aikatsu_gif

上の gif は上記手法でアップロードしたもの。 URL 見てもらえばわかると思います。

念のためスクショを貼っておきます。

f:id:mizukmb:20151208142238p:plain

アップロードできたら消去しちゃってOK。

使い捨てでいいから画像を使いたいって時に便利。