ホーム ブログ ページ 26

“同じ文字列”==”同じ文字列” => false

0

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

TL;DR

表示上は全く同じように見える文字列同士が==演算子でfalseを返すことがある。一つの原因として考えられるのはUnicodeが合成文字という仕組みにより濁音/半濁音を別扱いしているというもの。Unicode、また君か? 解決方法はUnicode正規化をすること。例えばrailsのActive Supoortなら以下のように正規化できる。

ActiveSupport::Multibyte::Unicode.normalize(string, :kc)

現象と原因の特定

この現象に遭遇したのはxmlからパースした文字列をrspecで期待値通りかチェックしていた時のこと。このように表示上は同じように表示されるが==(eq)演算子ではfalse扱い。

str1
#=> "電話番号 : 入力データが不正です"
str2
#=> "電話番号 : 入力データが不正です"
str1 == str2
#=> false

そこで、まずはバイトサイズを確認すると一致しない。そこでエンコーディングの差を疑って文字列のエンコーディングを確認するがこれも一致する。

[str1.bytesize, str2.bytesize]
#=> [54, 45]

[str1.encoding, str2.encoding]

#=> [#<Encoding:UTF-8>, #<Encoding:UTF-8>]

では何が違うかというと前述したとおり、str1では濁音/半濁音の記号が分離されている。これはString#unpackで文字列をコードポイントに変換したり、String#charsで文字単位に分割するとわかる。

str1.unpack("U*")
#=> [38651, 35441, 30058, 21495, 32, 58, 32, 20837, 21147, 12486, 12441, 12540, 12479, 12363, 12441, 19981, 27491, 12390, 12441, 12377]
str2.unpack("U*")
#=> [38651, 35441, 30058, 21495, 32, 58, 32, 20837, 21147, 12487, 12540, 12479, 12364, 19981, 27491, 12391, 12377]

str1.chars
#=> ["電", "話", "番", "号", " ", ":", " ", "入", "力", "テ", "゙", "ー", "タ", "か", "゙", "不", "正", "て", "゙", "す"]
str2.chars
#=> ["電", "話", "番", "号", " ", ":", " ", "入", "力", "デ", "ー", "タ", "が", "不", "正", "で", "す"]

これにはUnicodeの合成文字という仕組みが関係している。合成文字/結合文字(combining character)は非結合文字の直後に結合文字を配置することで結合文字列(CCS)を作る仕組みのこと。簡単にいえば「が」という文字列を「か(非結合文字)」「<濁音記号>(結合文字)」という2つのコードポイントで表してもいいということだ。ややこしいのが、Unicodeは「が」という一つのコードポイントで表しても良い点で、つまり同じ文字を表すのに異なるデータの表現方法がある。

当然、バイト列が違うのでそれぞれの表現でバイト数さえ食い違う。このままでは色々な問題が発生するため、これらのバラバラな表現を統一するように正規化することが出来る。

str1.bytesize
#=> 54
ActiveSupport::Multibyte::Unicode.normalize(str1).bytesize
#=> 45
ActiveSupport::Multibyte::Unicode.normalize(str1) == str2
#=> true

ちなみにUnicode正規化にはNFD、NFCなど複数の形式があり、上記のコードでは省略しているが、normalizeメソッドは2番めの引数に正規化形式を指定することが出来る。ex. normalize(str, :nfc)

ところで色々な問題が発生する、と書いたが面白いのはセキュリティに関する問題を引き起こすこと。文字列の比較はセキュリティに深く関わるトピックであり、XSSを防ぐためのエスケープにせよ、パスワードの認証にせよ、文字列が正しく比較出来ることを前提にしている。その前提をいじれてしまうのなら色々なことが出来てしまう。

考えられる他の原因

表示上は同じだがデータは異なる、という文字列比較のややこしい問題は他にも色々ある。やはり文字列データは非常に複雑なデータ形式ということだろうか。こういった問題が不完全な抽象化から抜け出せる日はまだ遠い。主が怒り全地の言葉を乱し人を全地に散らされたために人々は当面の間は苦しむ。

  • 非最短形式
  • 多対一の変換
  • 大文字と小文字
  • エンコード情報の不一致
  • 7ビットエンコーディングの解釈

Vimでファイル保存時に自動でrubocopを実行する

0

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

Rubyのコードを変更したら忘れずに Rubycop でチェックしたい。というときに使えるTipsです。

前提

  • Rubocop がインストール済みでrubocopコマンドにpathが通っていること

準備:NeoBundle のインストール

以下のページを参考に Vim に NeoBundle を導入します。(今時のVimプラグイン管理は dein.vim らしいのですが、自分の環境はまだ NeoBundle です…)

既に NeoBundle がインストール済みの場合、次の手順に進みます。

NeoBundleの導入 – Qiita

Vim に syntastic をインストールする

syntastic は Vim 上でのシンタックスチェックしてくれるプラグインです。

~/.vimrc に以下の行を追加します。

" syntastic インストール
NeoBundle 'scrooloose/syntastic'

" syntastic から rubocop を実行する設定
let g:syntastic_mode_map = { 'mode': 'passive', 'active_filetypes': ['ruby'] }
let g:syntastic_ruby_checkers = ['rubocop']

上記を簡単に解説すると…

  • NeoBundle 〜
    このの行はプラグインを使用することを NeoBundle に対して知らせるためのもので、もしそのプラグインがインストールされていなければ、vim の起動時に GitHub のしかるべき場所からローカル(標準では ‘~/.vim/bundle` の下)に clone して、vimのプラグインとして自動的に読み込んでくれる。
  • let g:syntastic_* = 〜
    この行は syntastic プラグインからRubocopを呼び出すための設定

これらを設定して Ruby のソースコードを編集して保存すると Rubocop のチェックが走ります。

実行してみる

ためしに以下のようなコードを入力して保存してみます。

class Hoge
  def foo
    puts "hoge"
  end
end

実行結果は以下のようになります。
警告が出てる行に$>が表示されます。また、:Errors と打つとエラーの一覧が表示されます。
他にもいろいろ便利機能あるので詳しくは、syntasticの公式ページを見て頂くと良いと思います。

enter image description here

これで、ローカルでrubocop流し忘れて jenkins おじさんに怒られずに済みますね。

参考

Rubocopをsyntasticを使ってVimから自動実行する – Qiita

コミュニケーション技術②

0

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

今回はコミュニケーション技術の一つ「コーチング」について紹介します。

前回の記事:コミュニケーション技術

コーチング

コーチング(coaching)とは、人材開発の技法の一つ。対話によって相手の自己実現や目標達成を図る技術である。相手の話をよく聴き(傾聴)、感じたことを伝えて承認し、質問することで、自発的な行動を促すとするコミュニケーション技法である。

出展:Wikipedia

コーチングの3原則

①インタラクティブ(双方向性)

インタラクティブとは一方通行の会話ではなく、双方向でアイディアを出し合い、それについて対等な立場で話し合うことを指します。

インタラクティブを促進するのに役立つスキルは「質問」や「ペーシング」です。大事なことは否定しないこと。答えは必ず相手の中にあるはずだからです。

②オンゴーイング(現在進行形)

継続性ともいわれますが目標達成までの間のサポートのことを指します。

「インタラクティブ」によって生まれた気付きは相手の行動を変化させます。
一時的にモチベーションは上がりますが徐々に下がっていきます。
目標へ到達するためにはたった一回の気付きだけでは難しく、コーチがリマインドを行いサポートすることが必要です。

③テーラーメイド(個別対応)

テーラーメイドとは相手の特徴や思考、行動パターンに注目してそれぞれへの対応方法を変えながら関わっていくことです。

人はそれぞれ違います。
人間100人いたら100人分の行動があります。
もちろん中には似たような行動もあるでしょう。
テーラーメイドを実現するためには「タイプ分け」が有効といわれています。

以上が「コーチング」の3原則になります。

しかし最終的な目標は自分自身で答えを見つけることです。
コーチングにおいては「オートクライン」を意図的に繰り返します。
最後にオートクラインについて簡単に紹介します。

おまけ

オートクラインの仕組み

enter image description here
オートクラインとは、医学用語で「自己分泌」という意味です。
今回のコーチングに関連したお話では「自分の行動、特に自分で発した言葉が自分自身に作用すること」を指します。

新たなアイデアや自問自答による気付きを発見する手法として有効とされています。
そして何より重要なのは自分の言葉であるということ。
自分自身の説得に本人の言葉以上のものはないと思います。

まとめ

今回の記事は「コーチング」の3原則
①インタラクティブ(双方向性)
②オンゴーイング(現在進行形)
③テーラーメイド(個別対応)

以上の3点を紹介しました。

次回はタイプ分けの手法「DiSC理論」について紹介したいと思います。

CoCProxyでリクエストを飛ばさずにWebクライアントをテストする

0

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

外部のシステムとの連携をテストしたいけど、気軽にそのシステムのAPIが叩けないとかいうときに役立つTips

CoCProxyとは

簡単に言うと、普段は何もせずリクエストを右から左に受け渡すが、ローカルにそのリクエストのホスト名とパスに相当する場所にファイルを置くと、実際にリモートにリクエストしたフリしてローカルのファイルの内容をレスポンスとして返してくれるプロキシという感じです。

GitHubが流行る前に CodeRepos という公開リポジトリがありそこにアップロードされていた Ruby 製ツールでしたが、現在その派生版として nginx モジュール版と、今回紹介する Node.js 版があるようです。

インストール

node.js 版をインストールは以下のとおり。

$ npm install -g cocproxy

基本的な使い方

適当な場所にディレクトリを用意(たとえば coc_test とする)してそこに移動。

$ mkdir coc_test
$ cd coc_test

リクエスト対象となるホスト名と同じ名前でディレクトリを掘って、その配下に差し替えたいリソースに合わせてファイルを配置する。

$ mkdir www.google.co.jp

まずは普通にアクセスしてみる

$ curl http://www.google.co.jp/index.html
<!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="ja"><head> ....

普通に Google から HTML ファイルが返ってくる。

次に、別のターミナルでCoCProxyを立ち上げ、、、、

$ cocproxy
Proxy stand by: http://localhost:8087
Used mock dir : /home/ec2-user/coc_test

今度はProxyを通してアクセスしてみる。

$ curl http://localhost:8087/http://www.google.co.jp/index.html
<!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="ja"><head> ....

まだ差し替えるファイルを用意していないので、今度も普通に Google から HTML ファイルが返ってくる。

次は、cocproxy でファイルを差し替えてみる。
以下のように www.google.co.jp/index.html にファイルを用意する。

$ cat > www.google.co.jp/index.html <<EOF
<!doctype html><title>hello</title>Hello CoCProxy.
EOF

先ほどと同じようにproxy経由でリクエストを投げてみる

$ curl http://localhost:8087/http://www.google.co.jp/index.html
<!doctype html><title>hello</title>Hello CoCProxy.

今度は CoCProxy によってファイルの内容に差し替えられたレスポンスが返ってきたことがわかる

RubyのコードからCoCProxy経由でアクセスしてみる

今度は先程と同様の手順を Ruby のコードで確認します。

# test.rb
require 'net/http'

Net::HTTP.start('www.google.co.jp', 80, :ENV) do |http|
  response = http.get('/index.html')
  puts response.body
end

Net::HTTPのドキュメントによると、#new や #start メソッドの第3引数に :ENV を渡すと環境変数 http_proxy が設定されていればそのProxyを経由するとあります。

試しに、最初は環境変数なしで確認します。

$ ruby test.rb
<!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" ...

普通に Google のコンテンツが返ってきました。
今度は、環境変数http_proxyを設定してみます。

$ export http_proxy=http://localhost:8087
$ ruby test.rb
<!doctype html><title>hello</title>Hello CoCProxy.

今度はローカルで用意したファイルの中身が返ってきました。

CoCProxy をProxyとして利用することでリモートに手を加えることなくレスポンスを変更することができることがわかりました。

まとめ

  • CoCProxy を使えばクライアント側のコードを変更せずにProxyでファイルを差し替えることができる
  • RubyのコードからProxyを利用する場合、そのライブラリに応じた設定が必要な場合がある
    • 標準ライブラリ Net::HTTP の場合、.new, .start メソッドの第3引数に :ENV を設定しているとき http_proxy 環境変数に値を設定されている場合そのProxyを経由してアクセスする

APIの時間占有率を簡単に調べてみた

0

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

ツールやgemを入れずに調べてみた。

 なるほど、ボトルネックはAPIに掛かる時間だけではなく、APIが呼び出される回数にも依存するのか、といつしか知ってから数ヶ月。
 RailsのAPIのどれが一番時間を占有しているのか取り敢えず簡単に調べたいなー、と思って特に何のgemとかも入れずに調べてみました。

準備

 取り敢えず、そのAPIの時間占有率を調べる為のデータ型を作ってしまおう。

 コンソール上で

bundle exec rails g model ApiOccupancyData

 マイグレーションを書き込み。最低限必要なのは、コントローラ名、アクション名、それからAPIの消費秒数と総呼び出し回数でしょう。

class CreateApiOccupancyData < ActiveRecord::Migration
  def change
    create_table :api_occupancy_datas do |t|
      t.string :controller_name, comment: "コントローラ名"
      t.string :action_name,     comment: "アクション名"
      t.integer :average_time,     default: 0, comment: "API消費秒数(ms)"
      t.integer :total_call_count, default: 0, comment: "API総呼び出し回数"
      t.timestamps
    end
    add_index :api_time_occupied_datas, [:controller_name, :action_name], unique: true, name: "api_name_index"
  end
end

 それで、最後にrake db:migrateしてモデル作成。

計測

 取り敢えず、ログを弄る、ログデータから取ってくるとかするのは、モンキーパッチをする必要がありそうだし、深く調べなきゃいけないし、色々時間が掛かりそう。
 というわけで、簡単にコントローラ全体にbefore_action, after_actionを掛けてしまって、時間を取ってしまうことにしました。

class ApplicationController < ActionController::Base
  before_action :set_time
  after_action  :recognize_time

  def set_time
    @start_time = Time.now
  end

 def recognize_time
    #ms単位で差を計測
    time_cost = ((Time.now - @start_time) * 1000).to_i
    #パラメータにコントローラ名とアクション名は入っている
    controller_name = params[:controller]
    action_name = params[:action]
    record = ApiOccupancyData.find_or_create_by(controller_name: controller_name, action_name: action_name)
    #平均時間を上書き
    record.average_time = ((record.average_time * record.total_call_count) + time_cost) / (record.total_call_count + 1)
    #総呼び出し回数を更新
    record.total_call_count += 1
    record.save
  end
end

 後はRailsを色々動かしてみて、データが貯まるのを待ちましょう。

出力

Railsコンソール上であとは、

ApiOccupancyData.order("average_time * total_call_count DESC")

 とでも打てば時間占有率が高い順にデータが列挙されていきます。
 そこから、API単位で詳しく見ていって、どこで時間が掛かっているか等、調べていけます。
 後、chart.jsで可視化とかをするとより分かり易くなったり。

API重み(絶対)
API重み(相対)

yumパッケージの中身を見たい

0

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

ときどきyumが提供するファイルを覗いてみたい時ありますよね?そんな時に使えるTips

確認した環境

  • CentOS release 6.9 (Final)

手順

例えば、php55-php というパッケージがあってその中身を確認したいと仮定し、まず対象の rpm を yumdownloader {パッケージ名} によって手元にダウンロードします。

# yumdownloader php55-php

上記の結果カレントディレクトリにphp55-php-5.5.21-5.el6.x86_64.rpm がダウンロードされました。
次に、以下のように rpm -qlp {rpmファイル名} でその中身を表示します。

# rpm -qlp php55-php-5.5.21-5.el6.x86_64.rpm
/opt/rh/httpd24/root/etc/httpd/conf.d/php55-php.conf
/opt/rh/httpd24/root/etc/httpd/conf.modules.d/10-php55-php.conf
/opt/rh/httpd24/root/usr/lib64/httpd/modules/libphp55-php5.so
/opt/rh/httpd24/root/usr/share/httpd/icons/php55-php.gif
/opt/rh/php55/root/var/lib/php/session
/opt/rh/php55/root/var/lib/php/wsdlcache

パッケージの中身が見れました。簡単ですね。

ざっくり解説

参考までにrpmコマンドの引数 -qlp php55-php-5.5.21-5.el6.x86_64.rpm の意味をざっくりと解説

  • -q 検索モードを表す(--queryの省略形)
  • -p{パッケージファイル} 選択オプション: 指定されたパッケージファイルを対象とする
  • -l 検索オプション:検jkkkkkkk索により見つかったパッケージのファイルの一覧を出力する

詳しくは man rpm などを参照してください。

競技プログラミングのすすめ

0

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

この記事は、競技プログラミングとは何か、その始め方について書いた記事です。

はじめに

こんにちは、最近めっきり寒くなってまいりました。
朝起きるのが辛くなってきたmotsukaです
今回は競技プログラミングについてお話しします。

競技プログラミングとは?

競技プログラミングとは、制限時間内に与えられた問題をプログラミングを使ってどれだけ早く正確に問いて競う競技です。俗にプログラミングコンテストとも言い、
出題者側はテストデータを配り、参加者はそのテストデータを読み込ませて
作ったプログラムからの実行結果とテストデータの実行結果が同じなら、そのソースコードを出題者に提出します。出題者が回答が正しいかどうかを判定し順位を決定します。

どんな問題があるの?

問題としては、簡単なものから数学的な知識を問うものまで幅広くあります。
例えば、「3の倍数の時はfizz、5の倍数の時はbuzz、15の倍数の時はfizzBuzzを出力してください」のような、いわゆるFizzBuzz問題的なものもありますし、動的計画法や深さ優先探索などのちょっとした数学の知識やアルゴリズムの知識が必要な問題もあります。ここでは紹介しきれませんので、下記で紹介するサイトなどで実際に解いてみてください。

どんなコンテスト、サイトがあるの?

TopCoder
URL:http://www.topcoder.com
世界最大規模の競技プログラミングコンテストです。
出題される問題は英語なので、英語に自信がある方は挑戦するといいと思います。私は英語ができなくて挫折しました。

AtCoder
URL:http://atcoder.jp
日本語の競技プログラミングコンテストサイトです。
毎週土日にコンテストを行っており、また初心者向けのコンテストや上級者向けのコンテストもやっているので初心者の方にもオススメのコンテストサイトです。週末のコンテストに参加すると、毎回解いた数に応じてレーティングが更新されます。

まとめ

これを機に、プログラミングコンテストに出場してみて、プログラミングを学ぶ一助になれば幸いです。
実力がついてきたと思えて来たら様々なオンラインコンテストを開いているサイトで様々な問題を解いてみてください

gitで詳しい変更履歴が見たい

0

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

git blame, git log を使ってちょっと踏み込んで変更履歴を見てみたい!そんな気持ちにgitは応えてくれます。 git blameとgit logの個人的によく使うオプションの紹介をします。

画像はいい画像がなかったのでgitのソースコードにgit blameしてみたものです。

特にblameするつもりはないのですが git blame が好きです。
blameという名前がよくないですが、だいたい本当にblameしたいときに出てくるのは自分の名前です。
コミットを追うことでコードの意図がわかりやすくなったり、書いた本人に質問や相談もしやすくなるのでバンバンやりましょう。

git blame

git blame は各行についての最終コミットの情報を表示してくれるコマンドです。

git blameの基本

基本的な使い方は git bleme <ファイル名> です。
これで指定した各行の最後のコミットについて、

  • コミットID最初8桁
  • コミットした人
  • コミットの時間
  • 今のその行

が表示されます。

こんな感じです。

df0ba296 (Hoge Hoge         2017-06-30 14:18:16 +0900  1) # coding: utf-8
df0ba296 (Hoge Hoge         2017-06-30 14:18:16 +0900  2) require 'slack'
df0ba296 (Hoge Hoge         2017-06-30 14:18:16 +0900  3) require 'uri'
c0bd872f (Fugaga Fuga         2017-06-30 14:18:16 +0900  4) require 'net/http'
df0ba296 (Hoge Hoge         2017-06-30 14:18:16 +0900  5)
00000000 (Not Committed Yet 2017-11-30 11:16:44 +0900  6) BOT_TOKEN = File.read("./bot_token").strip
00000000 (Not Committed Yet 2017-11-30 11:16:44 +0900  7)
00000000 (Not Committed Yet 2017-11-30 11:16:44 +0900  8) SHEETS_ID = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
...

特定の行だけ見る

これだけでも便利ですが、長いファイルだと目的の部分までたどり着くのが大変ですよね。
そういうときのために指定した行のぶんだけを表示させるオプション -L があります。

たとえば5行目から8行目だけ見たいときは git blame -L 5,8 <ファイル名> のように使います。

df0ba296 (Hoge Hoge         2017-06-30 14:18:16 +0900 5)
00000000 (Not Committed Yet 2017-11-30 11:16:44 +0900 6) BOT_TOKEN = File.read("./bot_token").strip
00000000 (Not Committed Yet 2017-11-30 11:16:44 +0900 7)
00000000 (Not Committed Yet 2017-11-30 11:16:44 +0900 8) SHEETS_ID = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"

git log

皆さんお使いであろう git log にも、コミットと変更の履歴が詳しく見られるオプションがあります。

特定ファイルに関するコミットのみを表示する

git log <ファイル名> で指定したファイル上の変更があったコミットだけを表示できます。

差分を表示する

-p オプションを付けると git diff で見られるような差分をコミットの情報の下につけてくれます。
ファイルは指定してもしなくても使えます。
こんな感じです。

commit 6813ebb5a01cbbf32e2f397a4afb1683dd94df8d (HEAD -> feature/design)
Author: Hoge Hoge <hhoge@example.com>
Date:   Thu Nov 30 18:40:05 2017 +0900

    画像差し替え

diff --git a/Assets/Scenes/Prefabs/Textures/bg.png.meta b/Assets/Scenes/Prefabs/Textures/bg.png.meta
index 550ba269..45d17bc0 100644
--- a/Assets/Scenes/Prefabs/Textures/bg.png.meta
+++ b/Assets/Scenes/Prefabs/Textures/bg.png.meta
@@ -12,6 +12,8 @@ TextureImporter:
     linearTexture: 0
     fadeOut: 0
     borderMipMap: 0
+    mipMapsPreserveCoverage: 0
+    alphaTestReferenceValue: 0.5
     mipMapFadeDistanceStart: 1
     mipMapFadeDistanceEnd: 3
   bumpmap:
...

行を指定する

-L オプションを付けるとファイルの行も指定できます。

たとえば git log -L 10,20:<ファイル名> でファイルの10-20行目について変更があったコミットだけを表示できます。
-p オプションを付けたときと同じように、そのオプションに関する差分も出してくれます。

まとめ

git blame も git log もどのコミットでどういう意図で追加・変更されたものなのか簡単に知れるとうれしいですね。
別に犯人探しのつもりはないので、名前に惑わされず平和で楽しいgit生活を送りましょう。

[参考]

SDキャラを可愛く描く②【装飾編】

0

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

SDキャラの装飾を可愛く描くためのポイントについてまとめました。

はじめに

nocoです。
前回に引き続きSDキャラを可愛く描くポイントについて考えまとめました。
今回は髪や衣装など装飾のデフォルメが主な内容となります。
体はもちろん、それを彩るパーツでキャラクターを可愛く見せてあげましょう。

装飾のデフォルメの基本

前回冒頭で使用した画像を用いてざっと説明いたします。
enter image description here
デフォルメはキャラクターの特徴的な要素を目立つように描くことが重要です。
このキャラクターの場合耳のような髪としっぽ、髪飾り、振袖が特徴です。
そういったパーツは通常の等身と比べ大きめの比率で描くことで個性が際立ちます。

また、細かいパーツは描写を簡略化すると印象がすっきり見えて可愛くなります。
体がデフォルメされている分衣装もある程度デフォルメしないとちぐはぐな印象になってしまいます。

それぞれのパーツの描き方

先ほどの画像では説明しきれなかった細部のデフォルメについてお話させていただきます。

①アクセサリーのデフォルメ

enter image description here

キャラクターの装飾としてよく使われるリボンを例に色々デフォルメしてみました。
パーツ一つのデフォルメでもさまざまな種類があります。
そのキャラに似合う、すっきり見えるデフォルメの度合いを選んであげましょう。
enter image description here
 

②髪のボリューム

enter image description here

毛を太くしたりハリをもたせたり、髪にボリュームのあるデフォルメをしてあげると可愛らしくなります。
特におでこのラインから飛び出す前髪、ここに少しボリュームを持たせてあげるだけでもかなり印象が変わるように感じられます。
 

③アホ毛を付ける

enter image description here

アホ毛は付けるだけでシルエットがとても可愛くなります。
オリジナルでも既存のキャラクターのデフォルメでも印象から大きく外れなければ付けてあげてもよいかもしれません。(特に個人的な意見ですが…)
アホ毛はキャラクターの感情表現にも使いやすく、SDキャラと相性が良いように思います。

おわりに

2回に分けてスーパーデフォルメについての記事を書かせていただきましたが、いかがだったでしょうか。
まだわたしもデフォルメについて勉強中の身ですが、今回の記事が少しでもイラスト制作のお役に立ちましたら幸いです。

簡易リグで綺麗なカメラの軌道を描く

0

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

はじめに

最近はカメラモーションを使った演出などを考える機会が増え、カッコいいカメラワークを模索しています。
というわけで、コンストレイントを使ってカットシーン制作などで必要になってくるカメラモーション用の簡単なリグを作ってみます。

コンストレイントって何だ?という説明については前回の記事で軽く触れておりますので割愛します。

カメラモーションは綺麗な軌跡を

カメラワークも想定したモーションにおいて、ダイナミックなシーンや注視点をより際立たせるために気をつけたいことがあります。

それが、
綺麗なモーション軌跡を描くことです。
見ていてカメラの動きに違和感を感じてしまうようだと、頑張って付けたお気に入りのキャラクターモーションや壮大な背景モデルが台無しです。

3DCGにおけるカメラの構造

MAYAでは、常にあるオブジェクトの方向を向かせるエイムコンストレントという便利な機能があります。
エイムコンストレントはキャラクターの視線や顔の方向を制御するために使われることがあるもので、カメラの注視点固定用にも使えます。

しかし、エイム対象とカメラだけを作成してそれらにキーを打ってカメラワークを作ろうとすると綺麗なモーション軌跡を作ることが難しくなってきます。

例えば背の高いオブジェクトを
下から上へオブジェクトを中心にその周りをぐるっと1周しながら近づいていくカメラワークを作るとします。
カメラの移動に直接キーを打って作ってみるとガタガタとした軌跡になりがちです。

画像1

また軌跡を綺麗にするためにはその分たくさんキーを打たなくてはならなかったり、
修正が出て1周ではなく2周するよう要望が出た際、作り直しにかかる時間が多いのと修正作業が大変なのとであまり賢いとは言えません。

グループノードでリグを作る

綺麗な軌跡を作りたい時はカメラに対してどのような動きをしてほしいかを考え、それに応じたリグを作ってあげることが無駄の出ない方法だと思います。
具体的な方法としてはカメラを適当なオブジェクトなどにコンストレインしその上に制御用のグループノード階層を作り、それらに対してキーを打っていくというやり方です。

画像2

画像の構造では最下層のcampointにカメラをポイントコンストレイントしてその上にある
cam_trsでローカルのカメラの移動を制御
cam_rttX、Yでグループノードの回転軸を中心としたカメラの移動を制御します。

今回は注視点を中心にしてカメラがY軸に下から上へ一周回転しながら近づいていく動きをしてほしいので
cam_trsでZ軸(中心に近づいていく軸)とY軸(上下に移動する軸)の移動にキーを打ち、一周回転はcam_rttYにてY軸回転値の開始フレームに0、最終フレームに360と数値を入力します。
こうすることでガタつきのない綺麗なモーション軌跡を描くことができるかと思います。(見えづらくて申し訳ないです)

画像3

キーを比較してみましょう。上がカメラの移動でつけたアニメーションカーブ、下がリグでつけたアニメーションカーブです。

画像4
カメラの移動で頑張ってつけたモーションはこんなにキーを打ってしまっているのに対し、
リグを使って付けたモーションでは開始フレームと最終フレームにしか打っていません。
2周にしてくれと要望が出た際はcam_rttYの最終フレームの値を360から720にするだけで済むので急な変更にも対応できます。

グループノードでは親の階層の動きが子の階層に継承されていくため 階層の順番 や 各ノードの中心軸 を慎重に考えながら作ることが注意点です。
また、rtt_X、Yのように回転をわざわざ分けている理由は一つのグループノードで3軸動かそうとするとジンバルを起こしてアニメートしづらくなってしまうためでもあります。

作り方は人それぞれですが場面に応じた作り方で作りやすいリグを考えて作る習慣を身につけると無駄な時間を費やす事にならずにすみます。

おわりに

今回の階層に分けたリグでアニメートする、という方法はとても初歩的なものですが、コンストレイントとリグを組み合わせて使っていくことでイメージ通りの動きを実現できるようになると思います。
筆者もたくさん試して応用力をあげたいところです。

sshの秘密鍵のパスフレーズを設定していたかどうか思い出せないとき

0

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

秘密鍵にパスフレーズを設定していたかどうか忘れた場合・またはパスフレーズが正しいか手元で試してみたい場合に使えるTips

以下のコマンドで確認する。

$ ssh-keygen -yf ~/.ssh/himitsu

パスフレーズが設定されていない場合は、秘密鍵を元に作成された公開鍵が出力される。

ssh-rsa AAAAB3NzaC1yc123xyz..... 

パスフレーズが設定されている場合は、パスフレーズの入力を求められ正しいパスフレーズが入力されれば同様に公開鍵が出力される。

Enter passphrase: (正しいパスフレーズを入力)
ssh-rsa AAAAB3NzaC1yc123xyz..... 

以下、man ssh-keygen からの抜粋。

    -y      This option will read a private OpenSSH format file and print an OpenSSH public key to stdout.

普通に手元の秘密鍵から公開鍵を作るのにも使える(それが本来の使いみち)

キャラクターの設定を管理する

0

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

度の高い項目を抜き出す

enter image description here
  • 一人称
  • 二人称
  • 三人称
  • その他、特殊な呼称
  • 口調
  • 性格の属性
  • 特技
  • 好きなもの
  • 苦手なこと
  • 嫌いなもの
  • 他キャラクターとの関係性

ほぼ必須となるのが上記の11項目でしょうか。
(特技と好きなもの、苦手なことと嫌いなものは纏めてしまっても良いかもしれないです。)
場合によっては増減しますが、これらを分かりやすくしておけば資料を見返すための時間はかなり短縮できます。
これに加えて、三行程度で簡潔にキャラクターの説明をメモしておくと、すぐにキャラクターを把握することが可能です。

忘れがちな裏設定などもメモ

enter image description here

全てのキャラクターに裏設定が存在するわけではないですが、書いているうちにどんどん追加で設定が足されていく……というのは多々あると思います。
そういった設定も逐一メモを書き残しておくと良いかもしれないですね。

終わりに

最初から設定の管理が出来ていれば、自分のド忘れだけでなく、他人に引き継ぐ場合にも役立ちます。
今までは設定をきちんと管理せずにやってしまっていたので、この記事は自分への戒めのために書きました。
後から管理しようとすると本当に大変なので、気を付けましょう。

Trelloで簡単タスク管理

0

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


タスク管理の方法は、紙に書き出す、付箋を使って管理する、タスク管理ツールを使うなど人それぞれだと思います。 今回は、私が普段から使っているタスク管理ツールを紹介します。

Trelloとは?

Trelloとは、Fog Creek Softwareが2011年に開発したウェブアプリケーションです。
基本的に無料で使うことができ、付箋を扱うのに近い感覚でタスク管理を行うことができます。
それでは、実際に画面を見てみましょう。
enter image description here
[Fig1. 初期画面]

何もない青い画面が出てきます。この画面を ボード と呼び、全ての付箋が集まる画面です。しかし、このままでは付箋を貼ることはできません。

画面の「リストを追加」からリストを追加しましょう。
enter image description here
[Fig2. リスト作成]

ここでは例として、[ToDo], [Doing], [Done]の3リストを作成しました。
1つのタスクを書いた付箋は、このリストの中に作成します。作成した付箋のことを、 カード と呼びます。
タスクには重要度や要件によってラベル(Fig2中、カードについている緑と黄色のタグ)を付けることができます。

カードはタスクの進行状況に合わせて動かすことができます。
enter image description here
[Fig3. カードを動かす]

これにより、タスクの進行度合いが視覚的に把握できます。

また、TrelloはスマートフォンやPC、タブレットといった様々な端末で使うことができます。
PCで使う際には、私はGoogle Chromeで利用することをお勧めします。
その理由は、便利なアドオンの存在です。

あわせて使うと便利なアドオン

Elegantt for Trelloについて

ガントチャートというものがあります。
これについては触れませんが、Elegantt for Trelloはカードからガントチャートを作成するというアドオンです。
画面を見てみましょう。
enter image description here
[Fig4. Elegantt for Trello]

ガントチャートが作成されています。

また、ガントチャートからタスクの進行度合いが分かります。
enter image description here
[Fig5. 進行度合い1]

「やること1」の進行度合いは0%となっています。タスクの進行に合わせてカードを右のリストに移動させることにより、進行度合いも増加します。

enter image description here
[Fig6. 進行度合い2]

逆に左のリストに戻せば、進行度合いは減少します。

Card Colors for Trelloについて

このアドオンを入れていない状態では、カードの色は白となっています(「やること2」、「やること3」のように)。
Card Colors for Trelloは、カードの色を一番最初につけたラベルの色、またはついているラベルの色を混ぜた色とすることができます。
これによって、カードの色から重要度、要件を判断することができます。より視覚的にタスクを管理できるということですね。

おわりに

Trelloは個人で使うも良し、チームで使うも良しの大変便利なツールです。
皆さんもガンガン使ってみましょう。

【cron × Gmail】バッチ実行エラーを手軽に監視しよう

0

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

今回のお話

こんにちは。いくたです。
宝塚歌劇公式サイトの更新を5分ごとに巡回して通知するボットを作りました。

このようにほぼ常時動いてるようなプログラムを組む時には、 何かしらエラーが発生した時に気づけるような仕組み が必要です。
今回はcronのメール送信機能を使って手軽にエラーの監視をしていきます。

cron以外にもスケジューラは色々とありますが、サーバーをわざわざ立てたりログローテーションを設定したりと面倒なことが多そうです。
そこでcronで使える お手軽 な運用・監視方法を考えました。

(ボットの紹介は今回の趣旨とは違いますが、よかったらフォローしてください。)
https://twitter.com/PolarChildren

このボットの大まかな仕組み

  1. サイトの更新履歴ページの一番上(最新)をNokogiriでスクレイピングして取得(スクレイピングについて詳しく知りたい方はこちらの記事もご覧ください)
  2. 前回の結果(テキストファイルに保存してある)と比べる
  3. 違いがあれば各所(twitter/slack/line)に通知する
  4. 新しい結果をテキストファイルで保存

この一連のプログラムを5分に1回動かしているのが cron です。

cronとは?

cronとはUnix系のOSで使われるシステムで、様々なコマンドを定時実行してくれます。
詳しい設定方法などはこちらの記事を参考にしました。

今回作ったボットのcron設定

$ crontab -l
# 実行時の出力内容をメールで送ってくれる(ボット専用のメールアドレスを取得)
MAILTO="test.mail.for.bot@mail.com"

# cronの書式
# 分 時 日 月 曜日 実行したいコマンド
# サイト更新監視バッチ(毎時間の0分から55分まで5分毎に実行)
0-55/5 * * * * /bin/bash -lc 'ruby ~/scripts/takarazuka/update_catcher.rb'

/bin/bash -lc の -l はログインシェルと同じ環境で実行したい時使うオプションで、 -c は引数にとった文字列( ruby ~/scripts 〜 以下)をコマンドとして実行するオプションです。

MAILTO を使うことで実行時の出力をメールに転送することができます。

# こんな感じのメールが来る
=====
From: サーバー
To: test.mail.for.bot@mail.com
Subject: Cron <サーバー> /bin/bash -lc 'ruby ~/scripts/takarazuka/update_catcher.rb'
-----
[debug] -- START --
[debug] loaded setting file.
[debug] execute: takarazuka
[debug] result is OK.
[debug] {:title=>"花組公演『ポーの一族』ムービーページ 更新!", :link=>"https://kageki.hankyu.co.jp/revue/2018/ponoichizoku/movie.html"}
[debug] This site is updated.
[debug] tweeted
[debug][message]
宝塚歌劇公式ホームページが更新されました。
【花組公演『ポーの一族』ムービーページ 更新!】
https://kageki.hankyu.co.jp/revue/2018/ponoichizoku/movie.html
[debug] -- END --
=====

メールを使ってエラー通知

ボット専用のメールは普段見ないのでエラーがあっても気づけません。
そこでエラーのログが出力されたメールを、普段使っているメールアドレスに転送するようにしました。

例外エラーをキャッチする

まず、プログラム内でエラーをキャッチして [error] と出力させます。
後々メールで出力結果を送った時に固定文字’error’でエラーメールを振り分けます。

puts '[debug] -- START --'
begin
  # サイトの更新を監視して通知する UpdateCatcher のインスタンスを生成・実行
  UpdateCatcher.new.execute
rescue StandardError => error
  # 例外エラーをキャッチして出力する
  puts "[error] #{error}"
end
puts '[debug] -- END --'

メールのフィルタ・転送を設定する

Gmailにはメールを条件で分けて処理するフィルタ機能があります。
Gmailのフィルタルールの作成方法

このフィルタ機能を使って、本文中に’error’が含まれるメールだけを自分のメールアドレスに転送します。
これで実行時に何かエラーが発生しても、すぐに気づいて対処できます。

# こんな感じのメールが来る
=====
From: サーバー
To: test.mail.for.bot@mail.com
Subject: Cron <サーバー> /bin/bash -lc 'ruby ~/scripts/takarazuka/update_catcher.rb'
-----
[debug] -- START --
[debug] loaded setting file.
[debug] execute: takarazuka
[error] Failed to open TCP connection to kageki.hankyu.co.jp:443 (getaddrinfo: Name or service not known)
[debug] -- END --
=====

メリット

メリット① 容量を気にしなくていい

RubyのLoggerを使えば割と簡単にログを出すこともできます。
しかし、サーバーにログを残すということは、多少なりとも容量を気にして管理することが必要です。

そこでログを出さずに全てメールで送ることでサーバーの容量を気にせず使えます。
(代わりにメールサーバーのディスク容量を圧迫していくので、自分のメールアドレスに全ログ送るのはやめましょう)

メリット② 必要な情報が検索しやすい

過去の実行状況を確認したいときも、送信日時(実行日時)やキーワードでメールを検索すればまとめて確認することができます。
個人的にはテキストファイルのログよりブラウザで確認できるほうが分かりやすくて気に入っています。

メリット③ Gmailのフィルター機能で応用が利く

Gmailのフィルター機能は細かくカスタマイズが可能です。
先ほどは転送機能を紹介しましたが、既読にしたりフラグを立てたりすることもできます。

Gmailのフィルタルールの作成方法

私の場合はエラーメール以外は既読にして、エラーメールはフラグをつけて後から探しやすくしています。

スクリーンショット 2017-11-29 13.34.41.png
エラーメールのフィルタ設定

デメリット

デメリット① 実行自体出来なかった場合気づけない

この仕組みはRubyが実行できる前提なので、なんらかの理由で実行ができなかった場合(ファイルが壊れてるとか)エラーを正しくキャッチできない場合があります。

# こんな感じのメールが来る
=====
From: サーバー
To: test.mail.for.bot@mail.com
Subject: Cron <サーバー> /bin/bash -lc 'ruby ~/scripts/takarazuka/update_catcher.rb.hoge'
-----
ruby: No such file or directory -- /home/ikuta/scripts/takarazuka/update_catcher.rb.hoge (LoadError)
=====

これだと ‘error’の文字列に引っかからないので自分のメールアドレスには転送されません。
本来なら、cronで標準エラーを受け取ってメールする設定をする必要があります。
その場合、Rubyで例外エラーをキャッチすると異常終了ではなく正常終了するので、スクリプトの方も工夫が必要です。

参考:
cronの設定について
Unix :: cron / 標準エラー(STDERR)のみアラートメールする

デメリット② 頻繁にメールを送るとスパム認定されるかもしれない

今の所問題なくメールは送られていますが、昼も夜もなく5分に1回メールを送っているのでGmailに目をつけられてスパム認定されてしまう可能性もあります。

デメリット③ 汎用性がない

ログとしてファイルに出力すれば、そのデータからいろんなことを分析することができます。
今回のボットでいえば、「サイトの更新がどれだけ頻繁に起きているか」とか「何曜日が一番更新されやすい」とかです。
しかし、今回はメールで全て送ってしまって手元に何も残らないので、出力を眺めることしかできません。

まとめ

今回紹介した方法は業務レベルでは使えませんが、趣味でやっている分にはこれで充分かと思います。

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

rubyで抽象メソッドを表現する

0

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

rubyについて調べていたら抽象クラス/メソッドをサポートしていないようでした。
ですが抽象メソッドのようなものを簡単に表現できるようなのでそれを紹介したいと思います。


オーバーライドしなきゃエラー!


抽象メソッドはオーバーライドを強制するのが目的なので、オーバーライドされてなければエラーする形で実装してやれば表現できます。

class GameObject

  # GameObjectを継承した描画の実行はこれを呼び出す
  def draw
    draw_proc
  end

  # これを子クラスでオーバーライドしないと
  # drawから呼ばれてエラーになる
  def draw_proc
    raise "call abstract !"
  end

end


class Circle < GameObject
  def draw_proc
    puts "丸だよ"
  end
end


class Box < GameObject
  def draw_box
    puts "四角だよ"
  end
end
circle = Circle.new
circle.draw
=> 丸だよ

box = Box.new
box.draw
=> RuntimeError: call abstract !

draw_procを継承していないBoxクラスから描画メソッドを呼び出したらちゃんとエラーを出してくれました。


おわりに


rubyでプログラミングしていて「これエラーにならないんだ」と思うところが多々ありました。
それもそのはずで、そもそもrubyの設計思想がストレスなくプログラムを楽しめるようにといったものらしいのですが、c++を使っていた自分からするとある程度縛りの効いたルールがある方が安心して動けるので、この記事を書くに至ったわけです。
でもせっかく自由に楽しくがモットーの言語なのにそれを制限するのも変な感じがするので自由さを生かすような設計をしていきたいですね。

【roo】ExcelファイルをRailsで読み込む

0

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

今回は使っていて便利だった、excelを読み込むライブラリ【roo】について書きたいと思います。

はじめに

 約10年ぶりぐらいにバッティングセンターに行ったらバットにボールがほとんど掠りもせずに全身筋肉痛になりました、むらさきです。
 今回は、.xlsxファイルから必要な情報を抜き出して使うことがあった時に利用したrooというライブラリについてまとめたいと思います。

rooとは?

 rooとはスプレッドシートの読み込みができるライブラリです。.xlsや.xlsx、.odsや.csvなどに利用できます。google spreadsheetにも利用できるようです。
 読み込み専用で書き込みや新規作成等はできません。

インストール方法

 rooのインストールは

 gem install roo

 で簡単に行えます。

使ってみよう

インストールが終わったので実際に使ってみましょう。
今回は下のシートを使用します。rooは読み込み専用のライブラリなので、データを読み込んで表示させてみます。

enter the description

1.読み込みたいファイルを指定する

require 'roo'

xlsx = Roo::Excelx.new(file_path)

.xlsxファイルを取得する際には上記のように読み込みたいファイルのパスを指定して書きます。
.xlsxファイル以外の場合は

Roo::Excel.new(file_path)             #.xlsファイル
Roo::Csv.new(file_path)               #.csvファイル
Roo::OpenOffice.new(file_path)        #.odsファイル

と書く事で指定できます。

2.使用するsheetを指定する

xlsx.default_sheet = 'spices'
xlsx.default_sheet = xlsx.sheets[0]

直接sheet名を入力するか、sheetsの配列から指定するができます。

3.指定したセルに入っているデータを表示する
例として「ターメリック」と「シナモン」を取り出したいとします。
「ターメリック」はシートの2行、2列目
「シナモン」はシートの5行、2列目なので

xlsx.cell(2,2)   #=> "ターメリック"
xlsx.cell(5,2)   #=> "シナモン"

とすることで取得できます。

4.ループで取得する
最後に、例として材料の名前だけをすべて表示します。

2.upto(xlsx.last_row) do |row|  
  p xlsx.cell(row, 2)    #2列目を1行ずつ取得する
end  #=> "ターメリック","ナツメグ","唐辛子","シナモン","クミン","コリアンダー"

おわりに

いかがだったでしょうか。読み込みだけですがとても簡単に扱える便利なライブラリでした。
rooという名前だったのでシートにカレーのスパイスを使ったんですがスパイスを調べる際にセルフ飯テロをかましました。カレー食べたい。

椅子が変われば環境も変わる?良い椅子のすすめ

0

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

作業環境を改善したいそんなときにデスクワークと密接な関係をもつ椅子の話です。

 腰痛肩こり眼精疲労・・・。日々長時間デスクワークを行うとこれらの体の負担も著しくなります。そこで日々の労働から体の負担を軽くしより効率よく作業できるような環境にするために重要なのが椅子です。今回は労働者の体に合わせて考えられたワーキングチェアについてお話いたします。

▼こだわりの3つの性能

 座っていても疲れにくい椅子は人間工学などあらゆる分野から考え抜かれたデザインをしています。具体的には以下の3点に注目し作られています。

体圧が分散されるデザイン

 物に座ると身体の表面に圧力がかかります。硬いものに座れば安定しているものの局部的に圧力がかかり、しかし柔らかいものに座れば圧力は分散されますが姿勢が崩れやすくなってしまいます。椅子の座面は体の圧力が分散され、かつ安定感を持って座れる程よい固さ追求しています。また体に沿ったデザインにすることで椅子との接触面積を広げることで、圧力の分散と姿勢保持を両立させています。
`

背骨が自然なS字曲線を描けるようなデザイン

 人間の背骨は2本足で立ったときのバランスをとるために常にS字のようなゆるやかなカーブを描いています。しかし座った途端このS字形状は崩れ、アーチ型に歪んでしまいます。そうすると腰や椎間板への負担も大きくなり、やがて腰痛や疲れ、内臓の圧迫などの疲労へと繋がっていきます。そこで注目されたのが背もたれの形状です。人間の背骨の曲線に合わせたデザインや骨盤を支えより安定感のある座り心地を追求したデザインなど、背骨に対するサポート機能が数多く備わっています。中には体が前すべりしてしまわないよう座面の一部に傾斜をつけたものもあります。

自分に合った高さに調節できる設計

 人間の体に合わせたデザインとはいうものの使う人によって体格の違いや姿勢差などが生じます。いくら良い椅子であっても足が届かなかったり、背もたれの曲線が合わなかったりすると折角のサポート機能も意味がありません。自分の身長や姿勢に合わせて座りやすい高さや角度に調整できることも椅子選びの中で大切な要素です。

▼こだわりの機能と形状

 3つの要素を追求した結果、そのこだわりは椅子の形状や付属機能に反映されています。
肘掛の有無や、もたれかかった方向へ傾くロッキング機能、背もたれ一つにしても背の高いものから低いものと多種多様です。

背もたれの高さ

 背もたれはおおまかに「ハイバック」「ミドルバック」「ローバック」の三種類の大きさに分かれます。背もたれの高いハイバックは頭部までもたれかけられるので首の負担が減ります。そのため1日3時間以上の長時間作業でも疲れにくい状態で過ごせます。ただしサイズも大きく部屋の広さによってはかなりの圧迫感が生じます。ミドルバックはハイバック・ローバックの中間の高さです。ハイバックのように3時間以上の作業にも適切、というわけではないのですが、ある程度の時間なら疲れ辛く作業ができ、部屋もあまり圧迫されないサイズ感となっています。最近ではヘッドレストが付属しているものが多いですね。ローバックは上記の二つよりも更に背もたれが低くコンパクトな印象。背が低い為視界を遮ることなく一人暮らしの部屋にほどよくおさまるサイズです。価格も一番安いのですが、長時間作業をするには不向きな為、1日1時間と短時間作業を行う人におすすめです。

肘掛

 肘掛があるとやはり腕の負担がかなり軽減されます。腕は体全体の16%もの重量をもっており、マウス作業やタイピングするときは宙吊り状態になりがちです。肘掛があることによって腕の重みが肘部分で分散され、かつ安定した状態で作業を行うことができます。また肘掛に肘を置いたポーズは肩甲骨周りの筋肉を休められるポーズにもなっているのでデスクワークの最中にこまめに行うのもおすすめです。
ただ、作業机の高さによってはひじかけが邪魔で机の下に収まらない場合もあります。購入の際は肘掛の高さが調節可能かどうかなのも含めて、机との兼ね合いも見ながらの検討が必要です。

ロッキング機能と高さ調節

 ロッキング機能があると椅子を自由な角度に傾けられるので椅子に座ったままで楽な姿勢がとれます。体に合った角度に倒したまま作業ができるという点でもポイントが高いですね。椅子の高さ調節は個々に違う机や画面の高さ、または使っている個人の脚の長さによって調節しなければならないので非常に重要です。まず、変更できる高さの中に自分の体に合った高さがあるもの。そして簡単に自分の好きな高さに微調整できるものがおすすめです。

前傾型後傾型

 ひとくくりにデスクワークといっても業種によって仕事中にとる姿勢は前傾と後傾の二種類に分かれます。前傾はアナログや液晶タブレットを使用したイラスト業務、もしくは作業をする際いつも前のめりになってしまう人にはうってつけです。後傾はキーボードでタイピングするタイプのものから何かと汎用性の高い姿勢がとれるようになっています。
後傾に比べ前傾タイプのものは数が少ないのですが、作業中によくとる姿勢を思い浮かべながら作業スタイルに合った一品を探すと良いと思われます。

▼今からできる作業環境の改善

 ここまで紹介してきましたが、高価なものや種類も様々でなかなか購入に踏み切れなかったり、手元に届くまで待つまでの間もどうにか作業環境を改善したいと思う場合もあります。
そんなときは
・画面を高くするなどして無理のない姿勢で作業できる環境にする
・腰の後ろや体の下にクッションを敷いて無理なく正しい姿勢で座る
・画面の明るさを下げ眼精疲労から来る肩こりを和らげる
といったことを試してみるのも良いかもしれません。

▼最後に

 そんな考え抜かれた椅子でも全ての肉体的負担から解放してくれるわけではありません。どんなに良い椅子に座っていても長時間作業すれば疲れは表れます。気分転換に立ち上がったり目を休めたりなど合間に休憩を取りながらデスクワークに励んでください。

Rubyで大域脱出

0

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

Rubyの大域脱出の紹介と、大域脱出のためにエラーを利用するなって話と、そもそも大域脱出を考える時は設計がおかしい可能性があるので考え直しましょうって話です。

はじめに

お疲れ様です、くろすです。

ようこそ、ここは黒魔術の入口だよ

大域脱出

rubyには大域脱出用のメソッドがあります。
throw..catchです。
普段書くようなコードで見るような関数ではないので、存在を知らない人も多いと思います。
動き的には普段見るコードで言う所のraise..rescueみたいなヤツです。
深いところからズバッと抜けられるので気持ちがいいです。

ただraise..rescueみたいなヤツと思って使うのはやめましょう、怪我の元です。

まず、raise..rescueですが、これは 例外処理 に使います。
例外クラスの部分を見ていただければわかると思いますが、ruby本体では例外をErrorの名を冠せず使ってる場所はかなり少ないです。
結果として大域脱出できますが、本質的にはエラーハンドリングのために存在しているよう思えます。

次に、throw..catchですが、これは大域脱出に使います。大域脱出専用です。
引数で指定したオブジェクトをthrowしないと怒られれます。

実用例

まず、エラーを大域脱出のために使っちゃったコードを見てみましょう。
なんとも運のいいことにが過去記事で使っちゃってるんですね。
肥大化するAIと対峙する時に覚えておきたいこと
この記事こんなことが書いてあります。

 (略)
 class NotIntelligence < StandardError; end

 def self.get_ai(code)
   # ai = AIManager.get_ai(code).new(code)のように呼ばれた時の大域脱出で使う
   raise NotIntelligence unless @codes_to_ai.keys.include?(code)
   @codes_to_ai[code]
 end
 (略)

アホになれないcodeを割り振られた子たちはNotIntelligenceエラーを返されるという、なんとも分かりにくい説明コードを書いてしまいました。

この記事では肝心の大域脱出に当たる部分が書かれていませんが、おそらくこんな感じになるかと。

(というか AIManager.get_ai(code).new(code) ってめっちゃ気持ち悪いですね、このコード書いたヤツだ )
ai = 
  begin
    AIManager.get_ai(code).new(code)
  rescue
    nil
  end

さあ危険な匂いがして来ましたね!!!
これでも動きます。残念ながら動いてしまいます。
NotIntelligence は StandardErrorを継承しているのでrescueで掬い上げられてしまいます。
全員が全部を理解して書いていれば問題ないのですが、そんなことは無理です。諦めましょう。

つまりこうすればいいんでしょ?

rescue NotIntelligence

と言われそうな気もしますが、そもそもNotIntelligenceはエラーではないのでrescue..raiseを使うのはやめましょう、というお話です。

throw..catchで書き直すとこんな感じですね。

def self.get_ai(code)
  unless @codes_to_ai.keys.include?(code)
    throw :not_intelligence, nil
  else
    @codes_to_ai[code]
  end
end
ai = catch :not_intelligence do
     AIManager.get_ai(code).new(code)
   end

そもそも使わなくていい

ここまで大域脱出について書きましたが、そもそも使わなくていい場合が多いです。設計を見直した方がいいと思います。
今回の場合はaiの定義場所を見たときどういう場合はaiが生成されないかを明確にしたかったのと、AIインスタンスを作成する場合にAIクラスが存在しない可能性があることを意識したくないので大域脱出を使用してますが、そもそもコメントで十分ですし、AIManager(Managerってクラス名も悪い)側で基本的なAIを必ず生成すれば使用する側からはAIがあるかないかを考えずに使用できます。
get_aiとかいうクラスを返す頭悪いコードもいらないですし、設計した私がアホです。

options = { code: code }
ai = AIBuilder.build_by(options)

class AIBuilder
  def build_by(code: nil)
    if @codes_to_ai.keys.include?(code)
      @codes_to_ai[code].new(code)
    else
      DefaultAI.new
    end
  end
end

こんな感じの方がいいですね。AIBuilderには@codes_to_aiが定義されてないので動かないんですけど。

じゃあどんな時に使えばいいのかという疑問がありますが、長いメソッドチェーンを途中で切り上げたい場合や、自前でvalidationを作る場合に他の処理と同列に書きたい場合などは大域脱出使えるんじゃないかと思います。
あまり見ないコードなのでわかりやすさは置いといてって感じになりますし、
効果的って意味じゃなく、あくまで使用可能って意味での「使える」って感じしかしないですけど。

複数ループの中から脱出したい & そのループの数をうまいこと減らそうとすると生成されてしまうarrayが要素数に比例してでかくなる & その要素数が外から操作できるので危険
みたいなすごく特殊な状況じゃないと使えない気がしますし、そんな状況だと普通の人ならメソッドにして値をreturnすると思います。

深い木構造の検索をかけて該当のものが見つかり次第脱出とかなら使えますかね……
もうちょっと面白い使い方ないかなぁ……

終わりに

関数途中のただ処理を切り上げるだけのreturnって、個人的には広義のgotoな気がしてあんまり使いたくないから大域脱出の紹介したんですけど、throw..catchほど直接的にgotoな感じはしないからうーん…って感じです。
returnに比べてthrow..catchの方が意味を持って処理を切り上げられる上に深いところからも脱出できるんで使い勝手いいんじゃないかとは思いますが、そういう目的だと実際に使えるかは微妙ってところですかね。

大域脱出のことを考えてたら、考えが継続渡しに流れ、schemeならcall/ccだなーと考えつつググるとどうもrubyにもcallccが黒魔術としてあるらしいことを知り、でもそんなコード誰も読めなくなってしまうと闇に葬りました。
ただ闇のコードは書いてて楽しいので、そのうち何か記事にするかもしれません。

【git】変更を一時退避する

0

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

pushしないといけない変更をpushしないまま、新たに中途半端に変更を加えてしまった時のコマンド
 

保存

まず現在の変更を保存します。
addとかしていたら全部戻します。

git stash save

このコマンドで保存ができます。(saveは省略可能です。)
これでdiffをチェックするとdiffがなくなっているので、pushができるようになります。

確認

保存されているのを確認するにはこのコマンドを利用します。

git stash list

このコマンドを利用すると

stash@{0}: WIP on sample_branch: 889808 commit_comment

というように一時保存したリストが出てきます。
もっと詳細な変更を見たい場合はこのコマンドを利用します。

git stash show <スタッシュ名>

<スタッシュ名>の部分にはリストに出てきた「stash@{0}」などを入れます。
このコマンドを利用すると

 sample.txt | 1 +
 1 file changed, 1 insertion(+)

このように変更したファイルなどを参照することができます。
 

変更を戻す

変更を戻すにはこのコマンドを利用します。

git stash apply <スタッシュ名>

あまりスタッシュが残ってしまうとどれがどれだかわからなくなってしまうので、削除も行います。

git stash drop <スタッシュ名>

リストを確認すると消えていることがわかります。
定期的に整理を行うことをおすすめします。
ちなみに、このコマンド

git stash pop <スタッシュ名>

復活させて削除、これら2つを一気に行ってくれます。
 

最後に

半年ほど前、初めて使った時に何をやったのか変更消してしまったので、二度と使うものかと思いながら仕事をしていました。
つい先日どうしてもその日にpushしないといけないものをpushしないまま新しいタスクに着手し、このコマンドを叩くことになりました。
今回は失敗しなかったので、またも備忘録です。
前回はpopとdropを間違えたのか?もう何をやって消してしまったのか思い出せませんが、気をつけて使用しましょう…。

モーション用ミニキャラクターの作り方②

0

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

はじめに

今回はキャラクターチップの表情差分の作り方をご紹介いたします。

表情差分

キャラチップを作成するのに重要になる一つが表情です。
表情はユーザーの視点が集まりやすく、演出にも関わる部分だからです。
喜怒哀楽のパターンがあれば大体の表現ができます。
enter image description here
まず設定に必要なパーツを考えます。
キャラクターの性格や現場のルールによって必要なパーツも変わっていくと思います。
アクションであれば攻撃をする勢いのある表情や、ダメージを受ければ痛い表情などがあるとモーションとして動かすのに魅力が出ます。

作る際のポイント

デフォルトの目を中心基準にして作っていき、パーツを切り替えた際に違和感がないようにします。
enter image description here
・目
笑顔のパーツなら瞼が下がるので、目の全体の高さが下がります。
描く時はデフォルト目の不透明度を下げて別レイヤーで上から描くとズレにくいです。

・口
これも目と同様通常状態のパーツから差分を作っていきます。
小さいパーツなので、遠目で見てバランスが合っているか調整していきます。
個人的には少し小さめに描いた方がちびキャラなどは可愛く見えるかと思います。

まとめ

量産する必要があるチップテクスチャは、パーツの型(骨組み)を使いまし装飾(髪型・服装・目など)を付けていくことが多いと思います。
そのため最初の型パーツを作成する場合はある程度先を見越して、後々問題点が出ても対応できるようおこなっていくのが大切です。

セオリーを知る ~プレイヤー編~

0

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

どんなジャンルのゲームにも「こうすべき」というセオリーは存在する。 セオリーを知らなければ損をするし、特に対人要素がある場合は致命的な不利へと繋がる。

セオリー初級 ~基礎プレイング~

 今回はセオリーとして分かりやすい対戦カードゲーム(※マジック:ザ・ギャザリングや遊☆戯☆王などのこと)を例にする。
 対戦カードゲームにおいて、「いかに盤面にモンスターを残して相手に攻撃を通すか」は最重要の課題となる。逆に「いかに相手の盤面にモンスターを残さず、攻撃を受けないか」というのも成り立つ。この観点から、デッキに採用するモンスターはできるだけ「やられにくい」「場持ちが良い」ものを選び、対戦時はモンスター同士のバトルで自分のモンスターだけが生き残るようにプレイするのがセオリーとなる。これが出来なければ勝てないと言っても過言ではない。

セオリー中級 ~逆転を意識する~

 初級で示したように、モンスター同士のバトルで対戦が進行する場合、先に盤面で有利を築いた側がずっと有利であることがままある。それを抑えるために対戦カードゲームではその状況をひっくり返すカードが用意されている。
 例えば「盤面のモンスターを全て破壊する」「相手にしかモンスターがいなければ簡単に出せる」といったものである。こういったものへの対策として、「手札に出せるモンスターはいるけど、全体破壊をされたら取り返しがつかなくなるからあえて出さない」といったプレイングが必要になる。ここが出来れば対戦ではまずまず勝てるようになってくる。

セオリー上級 ~セオリーを昇華する~

 例えば相手がモンスターを数ターン出さなかったらどうすべきだろうか。初級・中級から考えて、全体破壊を警戒して少量のモンスターで様子見しつつ攻撃するのが「最善」と言えそうだ。しかし上級者同士の対戦ではしばしば「最良」ではないことがある。つまり、「全体破壊を警戒されることを見越したプレイング」である場合だ。
 もちろん全体破壊をくらったら取り返しがつかないのだが、「最良のプレイ」は全力で攻撃することであったということが起こりうる。ここをできるだけ正確にするためには「全てのカードを知る」「相手が使ったカードを覚える」「相手のデッキを推し量る」ということが必須となる。「相手のデッキに入れられる全体破壊は5ターン目までは使用できない」ことが分かっていれば大きく有利になる。

まとめ

 ここで挙げた以外にもセオリーはたくさん存在するが、とりあえずこれらを押さえておけば戦うことは十分できるだろう。逆に知らなければ戦いにすらならないのは最初に述べた通りだ。
 今回は対戦カードゲームを例にしたが、「基礎」と「基礎のメタとなる逆転」があり、それらをより高度なものにする要素が大抵のゲームには存在している。もし伸び悩んでいるなら一度立ち返って考えてみてはいかがだろうか。

最近人気な記事