カテゴリー: テクノロジー

社内の空気をカイゼンする(物理的に)

先月の暑い盛りのこと、社内で異臭騒ぎが発生しました。
正確には会社の入っているビルで、です。

そのときに、臭いは記録できないからその場に居なかった人にひどさを伝えるのは難しいねという話をしたのですが、調べてみると臭いを測定できるセンサーというものがお手頃な値段で売っていることが分かったので使ってみました。
 

MQ-135

入手したのはMQ-135というガスセンサー。
臭いセンサーというより、特定の気体(アンモニア,二酸化炭素,NOxなど)による空気の汚れ具合を測定するもののようです。
この手のセンサーはそのままだと取扱いが意外と難しいらしいので、モジュール化されたものをAmazonで購入しました。およそ200円。中国から発送されて、届くまで2週間ほど掛かりました。

モジュールの端子は4つ。電源とGNDとデジタルアウトとアナログアウトです。
デジタルアウトは汚染レベルをざっくりと示すだけのようなので、今回はアナログアウトの方を使います。
これを Raspberry Pi に読ませるために、ADコンバーターが必要です。
以前買った実験キットにMCP3002というADコンバーターが含まれていたのでこれを使うことにします。

配線

SPIのお約束通りの配線ですね。
Raspberry Pi2 と MCP3002
* CE0とCS/SHDN
* SCLKとCLK
* MISOとDout
* MOSIとDin

MQ135とMCP3002
* AoutとCH0

raspi-config で SPI を有効にしておきます。

読み取りプログラム

WiringPi2-Python を使って読み取りプログラムを書きます。

#!/usr/bin/env python

import wiringpi2 as wp2
from datetime import datetime

SPI_CH = 0
PIN_BASE=64

wp2.mcp3002Setup(PIN_BASE, SPI_CH)
val = wp2.analogRead(PIN_BASE)
print datetime.now().strftime('%Y-%m-%d %H:%M:%S') + "\t" + str(val)

かなり高レベルなAPIを用意してくれてるので簡単です。注意点は以下の通り。
* CE0 に接続したので、SPI_CH は 0 を指定
* PIN_BASE は 64 以上ならなんでもいい。(63以下だと実行時に怒られる)

測定

身の回りで適当に測定したところ以下のような数値が得られました。
* 普段: 60
* コーヒー: 78
* 息を吐きかける: 159
* コーヒー後の息: 230
* 会社のトイレ: 70

この数値自体にあんまり意味はない(ちゃんと校正してなんらかの変換すれば意味のある数値になるのかもしれませんが)ので、普段の数値60との比較で考えるのが良さそうです。30%以上上昇したら換気を促すメッセージをSlackに投稿するとか。

およそ一日測定した結果をグラフにしてみました。

やはり人が居なくなると数値が下がり、出勤して人が増えてくると上がってくる感じです。0時過ぎの謎の上昇は何が原因でしょうね。

まとめ

それにしてもやっぱり人の吐く息って匂うんですね。
社員一人ずつ測定して大会を開くと面白そうですが、問題も大きそうなので思っただけにしておきました。

ゲーム開発 – 地形生成 アルゴリズム

こんにちは。開発担当のマットです。
 
以前の記事でも言ったことはありますが、ゲームが大好きです。
いろんなのゲームの中でも、とくに街づくりゲームが好きです。
 
街づくりゲームは沢山ありますが、内容はほとんどが似ていて何らかのマップの上で街を作っていきます。
しかし、一度成功すると二度目が面白くないので、毎回違う場所で街づくりをすることがポイントです。
 
そのため、ほとんどの街づくりゲームには、ランダム地形生成の機能が付いています。
なお、街づくりだけではなく、近年は多くのアクション・アドベンチャーゲームにも付くようになりました。
 

おそらく、Minecraftの影響ではないかと思います

 
このランダム地形生成機能に興味を持って調べたので、今回の記事では３つのアルゴリズムを紹介したいと思います。
 
今回紹介します3つのアルゴリズムを使えば、ランダムマップを生成するゲームをより簡単に作ることができると思います。

私のようにゲーム作成に興味をお持ちの方は、ぜひ読んでみてください。

１:フラクタル・アルゴリズム

個人的な意見ですが、フラクタルアルゴリズムは島や海岸の生成に向いているアルゴリズムだと思うので、島を作っていきます。
 
まずはグリッドを想像します。
5×5を使いますが、思いのままに作っても問題ありません。


 
次は、島の大体の形を決めます。
私は、ちょっと丸目の島が欲しいので角のセル（A1,E1,E5,A5)を削ります。


 
各セルの中のランダムな箇所に点（ポイント）を置いて、繋げていきます。


 
少し島の形に近づきましたが、まだ直線が多すぎて不自然です。
次は、各ポイントの間の位置を計算します。（以下で緑の点で表します）

 
それぞれの新しいポイントをランダムに左右上下にずらして、繋げ直すと島がよりギザギザになります。


 
先ほどよりも島の形が見えてきました。
 
このステップを何度か繰り返せば、本当に海岸のような線が出来上がります。
実際に作ったものはこちらです。

２:ダイヤモンド・スクエア・アルゴリズム

ダイヤモンド・スクエア・アルゴリズムはとても簡単で、上記のフラクタル・アルゴリズムのような島づくりには適していると思います。
また、フラクタル・アルゴリズムと違って地形の高度を獲得することができます。
 
前回と同じようにグリッドを作ります。
サイズは 2ⁿ+1 × 2ⁿ+1 にするのが1番無難なので、このサイズをおススメします。
 (つまり、5×5(2²+1 × 2²+1),9×9(2³+1 × 2³+1),1025×1025(2¹⁰+1 × 2¹⁰+1)など）
 
グリッドが出来上がったら、縁のセルの値を全部0にして真ん中のセルの値を1にします。
簡単な5×5のグリッドを例に説明したいと思います。


 
次は真ん中のセルと縁のセルの間のセルの値を計算します。
上記の例では、「真ん中のセルと縁のセルの間のセル」はB3,C2,D3,C4に当てはまります。

もちろん「間」と言ったら、「横縦の間」もありますし、「斜めの間」もあります。
この例では、「縦横の間」を使っていますが、実際に実装するときは両手段を併用するといいと思います。
ちなみに、このアルゴリズムの名前（ダイヤモンド・スクエア）はこの斜め、横縦を因んでいます。

間のセル（B3,C2,D3,C4）に、周囲のセルの数値の中間のランダム数値（もしくは平均値に近いランダム数値）を入れます。
C1が0で、C3が1となっているので、C2は0と1の間のランダム数値となります。

 
そのステップを繰り返し、全てのセルに値が入るまで続けます。
今、B3,C2,D3,C4の値を入れたので、次はB3,C2,D3,C4と縁の間のセルを埋めていきます。（つまりB2,D2,B4,D4)

やり方は色々あります。
例えばB2ですが、C2とA2の間のランダム数値を取ることもできますし、B3とB1の間のランダム数値を取ることもできます。
A2,B1,C2,B3の平均値に近い数値を取ることもできますし、A1,C1,B3,A3の平均値に近い数値を取ることもできます。
実装方法はプログラマーのお好み次第です。


 
最後に、全てのセルが埋まったら、高度の定義を行います。
例えば、0.2以下は海、0.7以上は山、その間は草、など。

 
上記の例はあまり綺麗ではないですが、ちゃんと実装すると以下のような島をランダムで生成できます。

高度値を使って、森林や川も生成することは可能です。

先ほど言った通り、島に適しているアルゴリズムだと思いますが、縁や真ん中の値を0,1ではなくて、ランダムな数値で始めると、山と谷のような結果になります。

３：パーリン・ノイズ・アルゴリズム

ゲームの地形生成では、パーリン・ノイズ・アルゴリズムは1番使用されているかもしれません。

パーリン・ノイズの詳細を説明することは本記事の範囲外となりますが（詳しくはWikipedia）、簡単に説明すると、波の生成アルゴリズムです。

多くのプラットフォームにライブラリーが存在し、使うことによって、ランダム波のノイズを生成することができます。


 
ダイヤモンド・スクエア・アルゴリズムと同じように、海や山の閾値を設定することによって、地形を作成することができます。
以下の地図は上のパーリンノイズをベースにして作成しました。

複数のパーリンノイズマップを重ねると、森林（深緑のエリア）なども生成できます。

まとめ

ゲームを作成するとき、リプレイアビリティ（繰り返し遊べること）は重視すべき要素だと思います。

この記事は街づくりのゲームの前提でアルゴリズムを紹介しましたが、これらのアルゴリズムを使えばRPG用の洞窟や宇宙ゲームの小惑星帯など、多くのエリアを自然に生成することができます。

毎回遊ぶとき、エリアが同じだとリプレイアビリティがなくなりユーザさんは遊ばなくなってしまうので、そうならないように、ぜひ上記の地形アルゴリズムを使って頑張って開発してみてください！

スマホ、Outlook対応！HTMLメールのボタンの作り方


HTMLメールを作ったけど、PC、スマホ両方対応しようとすると「ボタンを画像で作ったから大きすぎる、小さすぎる…。」などといった経験はないでしょうか？
「HTMLメールだから仕方がない…。」と画像で進めるのもありですが、ソースコードのみで対応できる方法がありますのでご紹介します。

 

「padding」を使えたら一番楽ですが、下記のように古いOutlookの場合、aタグに「padding」が対応していないようです。（代わりにborderを使おうと思ったのですが、10px程度までしか太くなりません…。）

The Ultimate Guide to CSS
https://www.campaignmonitor.com/css/
（「！」マークにツールチップで「Padding for p, div and a tags is not supported」と表示されます）

 

そのため、Outlook用のハックを利用します。





  
    Googleにリンク

「<!– [if gte mso 9]>〜<![endif]–>」とは、「Outlook 2000（Version 9以上）」のみ読み込むというハックです。
※以前ご紹介しました、スマホでもPCでも読みやすい！HTMLメールのフォントサイズを参照

 

その中に書かれている「<v:roundrect>」「<w:anchorlock/>」「<center>」はVMLタグらしく、そのタグで図形を描画しているようです。
なんだかややこしそう…と思っていたら、下記のジェネレータがありました。

 

Bulletproof email buttons
https://buttons.cm/

このジェネレーターでボタンを作成すると、Outlookにも対応した形でコードが生成されます。Outlook用のボタンは、幅と高さは固定されてしまうので、文字の量等に対応した調整はその都度必要です。

 

簡単なご紹介となりましたが、HTMLメールでボタンを作る際に参考になれば幸いです！

 

デザインパターンとアハ体験

専門学校の時に初めてプログラミングに触れて、ある程度自分の作りたいものが作れるようになったぐらいの時期に、デザインパターンの触りだけ授業で知る機会がありました。

 

そこで出会ったのがデザインパターンの１つである
Singleton(シングルトン)パターン

 

簡単に説明すると
「classから作られるインスタンスが必ず１つだけと保証できる作り方の考え方」

 

学生時はこのパターンを知るまでアクセス修飾子であるpublicとprivateを分ける意味がただ単にそういうものという認識でした・・・が、このSingletonを学ぶことでprivate修飾子を使う意味を初めて理解できた気がします。

 

[簡単なシングルトンパターンのコード例]

 

そこからデザインパターンを自分でも色々調べて、その度に今まで作っていたやり方はこうゆうパターンだったのか・・や、こんな考え方もあったのかと色々とアハ体験を経験した気がします！

 

デザインパターンがプログラミングをするのに必須というわけではないですし、なんでもかんでもデザインパターンというわけでもないですが、考え方を学ぶことで広がる世界や知っているもの同士の共通言語フレームワークやライブラリの中を調べる時の糸口になったりならなかったりと、そういったものがあることだけでも知っていれば少しは役に立つ・・・かも？

 

プログラミングをはじめてからある程度自分で作れるようになった人は興味があれば一度調べてみると面白いかもしれません。

ちなみに当時の私は面白かったです！

WordPress開発快適化計画 ~ Wordmoveの簡単導入とメリット・デメリット ~

早く冬が来ないかなとソワソワしているノリフミです。

前回、VCCW on WP-CLIにてWordPressの使い方を紹介しました。

WordPress開発快適化計画 ~ VCCW on WP-CLIを使ってみた ~

Wordmoveを使用してみて、Wordmoveだけでは割と限界があることに気づいてしまいました。

今回はもっと簡単にWordmoveを導入する方法と運用に当たってのメリット・デメリットをご紹介します。

※ 当記事では、Vagrantをインストール済みで、サーバーでWordmoveを公開しており、そのサーバーへssh接続できるものとして話を進めます。

目次

  1. Wordmoveの現状
  2. 今回の妄想
  3. Vagrantで環境構築
  4. Gitの設定
  5. Wordmoveの設定
  6. Wordmoveの使い方
  7. まとめ

Wordmoveの現状

コマンド

init (wordmoveの設定ファイルであるMovefileを生成)

pull (指定環境を元に同期する)
push (実行環境を元に同期する)

-w, [–wordpress], [–no-wordpress]
-u, [–uploads], [–no-uploads]
-t, [–themes], [–no-themes]
-p, [–plugins], [–no-plugins]
-m, [–mu-plugins], [–no-mu-plugins]
-l, [–languages], [–no-languages]

機能フォルダ単位を同期するオプション

-d, [–db], [–no-db]

DBを同期するオプション

-e, [–environment=ENVIRONMENT]

同期環境を複数設定した際に環境を指定するオプション

[–all], [–no-all]

文字通り全てを同期するオプション

メリット

  • ローカル、サーバー間などの別環境のファイルからDBまで簡単に同期できる
  • 同期コマンド(pull,push)にオプションをつけると機能フォルダ別に同期できる
  • 複数環境も設定ファイルに定義しておくと-eオプションで簡単に同期できる
  • 同期時にDBのバックアップがとられる

デメリット

  • ファイル単位の同期はできず、機能フォルダ単位でしか同期できない
  • ファイルの差分は無視される(恐らく更新日時の新しいものが同期される)
  • 差分が無視されて同期されるため、古いファイルは消滅する
  • 間違えてpullやpushしたら取り返しがつかない

今回の妄想

wordmoveとgitを使った管理を表した画像

Wordmoveは複数人開発の際、上記デメリットの点を引き起こしがちです。
今回の妄想ではWordmoveの役目は主にDBの同期とし、ソース管理はgitに任せます。

 

Wordmoveで管理する項目

  • アップロード系の変更 ( -u )
  • プラグイン系の変更 ( -p )
  • language系の変更 ( -l )
  • WordPress自体のバージョンアップ ( –all )
  • その他DBの変更 ( -d )

テーマ以下は基本的にDBに影響を与えないため、git管理とします。

 

作業の基本的な流れ

  • ローカルに環境構築
  • ローカルで作業を進める
  • stagingに作業分を同期し、テストする
  • productionに作業分を同期し、確認する
  • gitにcommitする

複数人開発時、上記工程後の他メンバーは

Vagrantで環境構築

＃ 適当なフォルダを生成
mkdir wordpress
cd wordpress

# Vagrantfileを生成し設定する
vim Vagrantfile

# nginx設定ファイルを生成
vim nginx.conf

# 設定したipとドメインをhostsに追記
sudo sh -c 'echo "192.168.33.123 example.com" >> /etc/hosts'

# 設定問題なければVagrant起動
vagrant up

…

….

…..

ここ割と長いですが、最後まで無事終了すれば環境構築完了です。

 

ブラウザからアクセス後、サイト情報を入力し初期設定を完了させてください。

上記構成だと

サイトURL : http://example.com
mysqlユーザー : root
rootユーザーパスワード : root
mysqlデータベース : wordpress

になります。

Gitの設定

初回登録の場合

# Git管理を始める
git init

# 全てをGitに登録する
git add --all

# 確定させる。適宜mオプションでコメント設定
git commit -m 'wordpress install'

# 初めてのpushなので先にRepositoryの場所を決める
git remote add origin GITURL

# branchを設定してpushを実行する
git push -u origin master

決まり文句ですね。

既存Repository使用の場合

# srcディレクトリ削除
rm -rf src
# Repositoryをsrcの名前でclone
git clone GITURL src

 

※ GITURLは適宜Gitの対象RepositoryのURLに変更してご利用ください

Wordmoveの設定


# Wordmove設定ファイル修正
vim src/Movefile

コメントがある箇所と、local部も調整した場合は適宜設定してください。

※ local + 1環境(productionのみなど)の場合、wordmove push or pull時にeオプションにて同期先環境を選択する必要はなくなります。

Wordmoveの使い方

Vagrant内にWordmoveをインストールしているため、Vagrant内のドキュメントルートまで移動する必要があります。

# Vagrant内に接続
vagrant ssh
# ドキュメントルートまで移動
cd /vagrant/src

使用例1（プラグインをインストールし、テーマ以下の調整を行なった場合）

  • 改修者がstagingに同期し確認後、productionへ反映、最後にgitに反映
    wordmove push -e staging -dpt
    wordmove push -e production -dpt
    git commit & push
  • 他メンバーがデータ同期
    wordmove pull -e production -dp
    git pull

使用例2（ブログ引っ越しにて過去記事の画像付きインポートを行なった場合）

  • 改修者がstagingに同期し確認後、productionへ反映
    wordmove push -e staging -du
    wordmove push -e production -du
  • 他メンバーがデータ同期
    wordmove pull -e production -du

その他コマンドについては、上記をご参考ください。

まとめ

これだけ長々と書きましたが、、、
一人の場合はWordmoveだけで管理し、キリのいいところでgitに反映すれば問題ないと思います。

複数人の場合はWordmoveを使った際に、予期せぬ消滅が多々あるので、DB関連の同期のみにしたほうがいいですよ！

というお話でした。

最後までご覧いただきありがとうございました！