こんにちは。10月に入社しました三浦です。

10月22日に弊社の引っ越しがありました。
いくつもの机や椅子を組み立てて、新オフィスでの業務を迎えています。
組み立て中は、別の方が持参した電動ドリルが大活躍しました。
バッテリー切れでヘトヘトになっていたので、持ち主の方から電気をもらっていることを祈ります。

さて本題ですが、今回はsymfonyの起動コマンドをコマンドラインで生成させてみます。
symfonyを自習していた当初、手動でifconfigを打ってIPアドレスを確認してからコマンドに入力していましたが、
何回も打っていたのでIPアドレスを自動で取得できる方法を考えてみました。

今回のテーマ

linux搭載のコマンドだけで、symfony起動コマンドを生成する。

前提条件

以下条件の下で、ホストOSのWebブラウザからsymfonyサイトにアクセスすることを考えます。
1. ホストOS：Windows10、VM：ubuntu18.04
2. 両方ともIPアドレスはDHCPによる自動付与とする。
3. VM上でsymfonyを稼働させる。

ポイント

3の前提より、単にserver:startを実行するだけではアクセスできません。

php bin/console server:start

代わりに、アクセスするIPアドレスとポート番号を明示して起動します。

php bin/console server:start {VMのIPアドレス}:{port番号}

IPアドレスの取得

ifconfigの出力結果から、IPアドレス(XXX.XXX.XXX.XXXの部分)を抜き出してみます。
ここでは、ホストOSと通信できるVM側のNICをeth0とします。

$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet XXX.XXX.XXX.XXX  netmask YYYY.YYY.YYY.YYY  broadcast ZZZ.ZZZ.ZZZ.ZZZ
        inet6 aaaa::bbbb:cccc:dddd:eeee  prefixlen 64  scopeid 0x0<global>
        ether ff:gg:hh:ii:jj:kk  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ifconfigの結果から抜き出すコマンドは以下の通りです。

echo `ifconfig eth0 | grep inet | grep -v inet6 | awk -F' ' '{ print $2 }'`　…　(a)

symfony起動コマンドの生成

(a)のコマンドを実行して出力されるIPアドレスをシェル変数に格納し、symfonyの起動コマンドを作成します。
なお、ポート番号は8000番を指定しています。

cd {起動するプロジェクト名}
SERVER_IP=`ifconfig eth0 | grep inet | grep -v inet6 | awk -F' ' '{ print $2 }'`
php bin/console server:start ${SERVER_IP}:8000

もう一工夫する

symfony起動中の時に server:start を実行するとエラーになってしまいますので、symfonyが停止中の時だけコマンドを発行するようにします。
今回は、プロジェクトフォルダ直下に「.web-server-pid」がなければ、symfony停止中と判断します。
if文を使って、symfony停止中の判断を追加します。

cd {起動するプロジェクト名}
if [ ! -f .web-server-pid ]; then
  echo `ifconfig eth0 | grep inet | grep -v inet6 | awk -F' ' '{ print $2 }'`
  php bin/console server:start ${SERVER_IP}:8000
fi

これで、IPアドレスを都度取得してsymfonyを起動するコマンドが出来上がります。
別ファイルに保存して適切なパーミッションを設定すれば、ワンタッチでsymfonyを起動するシェルとになります。

最後に

小さいコマンドながら、自分で作れたときは達成感を感じました。
これからも学ぶことは多いですが、今回のような達成感を糧に進んでいきます。

はじめに

こんにちは、イメージ・マジックの矢野です。入社から2か月が経過し、順調に机の上がゴチャゴチャしてきました。カメラが2台、バーコードプリンターが2台、小さなスピーカーが1台、さらにカードリーダーが1台、デスクの上に転がっています。

印刷しているもの

当社が印刷しているのは、Tシャツやパーカー、マグカップ、カーペットなどの製品そのものももちろんですが、それだけではお客様のお手元に製品を届けることはできません。生産工程でそれらを管理するためのラベルシールや、納品書、配送業者さんにお願いする送り状なども自社のシステムで印刷しています。当然といえば当然なのですが。

ラベルシールの印刷には、専用のプリンターを使用しています。私は転職してきて初めて触りました。ずんぐりむっくりでかわいい形ですが、言うことを聞かせるのはなかなか難しいです。プリンター専用のツールやライブラリを使ってバーコードや文字列や画像を出力するように指示することもできますが、プリンターの制御用コマンドを直接（「直接」とは言っても、通り抜けなければならないレイヤーは多数あります）送信することもできます。

ところで、「プリンターで何かを印刷する」というのはどういうことなのでしょう？　それは文字列や画像、バーコードを印刷しなさいというコマンドの積み重ねです。ラベルシールにバーコードを印刷する場合には、最終的にたくさんのしましまが紙面に出力されるようなコマンドをアプリケーションで生成して、それをプリンターに送信する必要があるわけです。

たくさんのしましまを、どうやってプリンターに送信しましょうか？

1. しましまを1本1本引くコマンドを生成して、順番に実行する
2. バーコード全体の画像をPNGなどのラスター画像で生成して、画像を印刷するコマンドを実行する
3. 「このデータ(ID)に対応するバーコードを、このバーコード規格を使ってイイ感じに生成してよ」とプリンターに任せるコマンドを実行する
4. その他

1も2も3も正解ですが、1は特に厳しい。バーコードの仕様に従って、1本1本のしましまの太さと間隔をどうにかこうにかしなければなりません。2は割とよくあると思います。バーコード画像を生成するライブラリを使用すれば、割とサクっとできるでしょう。でも、せっかく専用のプリンターを使っているのですから、彼（彼女？）に任せてしまってみましょう。

イイ感じにやってもらう

Windowsで、Win32 APIを使って実装してみます。プリンターによろしくやってもらう代わりに、プリンター固有のお作法に従わなくてはなりません。ここでは、Zebra Technologies社のプリンタ向け言語、ZPL（Zebra Programming Language）のコマンドを実行しています。

int PrintRawCommand()
{
	HANDLE hPrinter;

	if (!OpenPrinter((LPSTR)"Printer Name", &hPrinter, NULL))
	{
		// エラー処理

		return FALSE;
	}

	DOC_INFO_1 docInfo;
	docInfo.pDocName = (LPSTR)"Barcode sample";
	docInfo.pOutputFile = NULL;
	docInfo.pDatatype = (LPSTR)"RAW";

	LPSTR command = (LPSTR)"^XA^FO40,40^BY3^BEN,40,Y,N^FD123456789012^FS^XZ";

	if (StartDocPrinter(hPrinter, 1, (LPBYTE)&docInfo))
	{
		if (StartPagePrinter(hPrinter))
		{
			DWORD writtenBytes;
			if (WritePrinter(hPrinter, command, strlen(command), &writtenBytes))
			{
				// 印刷成功時の処理
			}
			else
			{
				// エラー処理

				return FALSE;
			}
		}
		else
		{
			// エラー処理

			return FALSE;
		}
	}
	else
	{
		// エラー処理

		return FALSE;
	}

	EndPagePrinter(hPrinter);
	EndDocPrinter(hPrinter);
	ClosePrinter(hPrinter);

	return TRUE;
}

15行目で、プリンタへ送信するデータの形式をRAW（生＝Zebraのプリンターが解するコマンドを直接送信する）に指定します。17行目の文字列が実際にプリンタへ送信されるZPLのコマンドです。レイアウト、フィールド、バーコードの表現形式（EAN-13）、バーコード化したいデータ（123456789012）などを、 ^ で始まるコマンドで指定します。

これの出力結果がこうなります。

EAN-13の詳細な仕様を隅々まで探らなくても、難しい画像操作系のAPIを駆使しなくても、美しいバーコードを得ることができました。

はじめに

イメージマジックの宮川です。

寒暖差があって、体調崩しがちですね。
風邪、気を付けてくださいね。（ひきました 笑）

さて！ということで！今回は業務で検討したFAX送信製品の比較についてです。

FAX送信 製品比較検討

弊社で開発中のWebアプリからFAX送信可能なAPIを検証しました。
基本的には、FAX送信時にFAXする対象をpdfに変換して、PDFのURLやファイル自体を送信する必要があります。
（PDF以外も対応可能）

調査したところ、以下の3製品がHITしましたので、それぞれ検証してみました。
・twilio
・eFax
・interfax(日本サイト)

※interfaxは日本サイトと海外サイトで若干記載が異なりましたが、日本サイト版の結果を記載します。

弊社では、twilioを導入しました。理由は、pdfしか使用しない点、HTTPリクエストに対応していて、導入が簡易的だったからです。
（固定コストが安く、サービスのスイッチもしやすい。また、他サービス（電話）なども使用可能）

以下、検証結果です。参考までに。
※コストなど、社内では細かく算出しましたが、記述粒度が細かくなりすぎるため、ここでは割愛しました。

twilioサンプルコード(php)

以下のようなサンプルで、twilioでFAX送信できます。

<?php

// Update the path below to your autoload.php,
// see https://getcomposer.org/doc/01-basic-usage.md
require_once '/path/to/vendor/autoload.php';

use Twilio\Rest\Client;

// Find your Account Sid and Auth Token at twilio.com/console
$sid    = "ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX";
$token  = "your_auth_token";
$twilio = new Client($sid, $token);

$fax = $twilio->fax->v1->faxes
  ->create("+15558675310", // to
    "https://www.twilio.com/docs/documents/25/justthefaxmaam.pdf", // mediaUrl
    array("from" => "+15017122661")
);

print($fax->sid);

参照：
Twilio Programmable Fax Quick Start

はじめに

こんにちは、イメージ・マジックのもあいです。
弊社開発部ではVirtualBoxを使ってローカルに開発環境を作成して開発を行っていますが、開発環境作成ではVagrantとAnsibleを使って自動で環境を作成しています。
今回は、この開発環境作成で便利なスナップショット機能を多用していましたので、どういった状況でどう使っていたのかを軽く説明します。

Vagrantとは

詳しくはWikiPedia等で確認してください。環境構築用ファイルから自動的に仮想マシンを作成して設定を行えるものです。
会社ではUbuntuをサーバOSとして使用していますので、BoxイメージはUbuntuの提供元が用意しているものを使用しています。

スナップショット機能とは

Vagrant+Ansibleで開発環境を作成するということは、Ansibleスクリプトを実行して正しい状態になることを確認します。
Ansibleスクリプトでは内容にもよりますが、設定変更が必要なときだけ設定変更を行います。
ということは、1回目と2回目で実行内容が異なるというわけです。テストではどちらの挙動も確認する必要があるのですが、
そのたびにVagrantで仮想マシンを破壊/作成を繰り返すのは非常に時間が掛かります。

そこで、VagrantにはVirtualBoxのスナップショット機能を簡単に使うコマンドが用意されていて

vagrant snapshot save foo

とすることでスナップショットを保存することができます。
この状態でAnsibleスクリプトを実行して、環境を戻したい場合は

vagrant snapshot restore foo

とすることで、スナップショットをとった状態に戻すことができます。
これでAnsibleスクリプトの再実行の時間が大幅に短縮されます。
fooとかいてあるところは名称ですので、いくつかスナップショットをとることもできます。

はじめに

こんにちは。イメージ・マジックの矢野です。入社からもうすぐ1か月です。

Node.jsのアドオンを、何らかの理由でネイティブのコードで書かなければならないことがあります。Node.jsのエンジンであるV8のお作法に則って書くことになりますが、V8がバージョンアップして仕様が変われば、そのお作法も変わります。お作法が変わればアドオンの書き方も変えなければならず、毎度毎度書き直すのは大変。そこで、Node.jsのネイティブなアドオンの実装をイイ感じにラップして抽象化してくれる、NAN（Native Abstractions for Node.js）というものがつくられたとのこと（READMEの冒頭を読むと、クスリとさせられます）。もちろんNANを使わなくてむ作れるわけですが、せっかく便利なものがあるのですから、使わない手はありません。

準備

Node.jsのアドオンをつくるのですから、当然Node.jsはインストールされていないといけません。

NANはnode-gypでビルドするため、node-gypもインストールしておかなければいけません。さらにgypはPythonスクリプトなので、Pythonが入っていなければインストールしておかなければなりません。

ネイティブコードをビルドするために、コンパイラなども必要です。今回はWindowsを使って開発しているので、Visual Studio 2017をインストールしておきます。

作成

準備ができたところで、作業用のディレクトリを作成します。

mkdir hoge
cd hoge

NANをインストールします。

npm install --save nan

binding.gypを作成します。このテキストファイルには、アドオンの構成を記述します。ネイティブならではのアドオンをばっちり作り込むのはそれなりに大変なので、今回はOSのバージョンを取得するだけの簡単なものにしようと思います。

{
  "targets": [
    {
      "target_name": "getosversion",
      "sources": [
        "src/addon.cpp",
      ],
      "include_dirs": [
        "<!(node -e \"require('nan')\")",
      ],
    }
  ]
}

ソースファイルを格納するディレクトリ（src）をつくり、ソースファイルを形だけでも（空ファイルでOK）つくっておきます（src/addon.cpp）。

node-gypでconfigureすると、上記の構成に従ってVisual StudioのC++プロジェクトやソリューションを生成してくれます。

node-gyp configure

buildディレクトリの下にいろいろファイルができています。

│  binding.gyp
│
├─build
│      binding.sln
│      config.gypi
│      getosversion.vcxproj
│      getosversion.vcxproj.filters
│
└─src
        addon.cpp

binding.slnを開くと、Visual Studioが起動しますので、addon.cppの中身を書いていきます。NANの恩恵を受けるには、ヘッダファイルnan.hをincludeしておく必要があります。
Win32 APIのGetVersion()を呼び出して、OSのバージョン情報を取得してみます。ちなみにこの関数は現在「非推奨」になっていますが、Win32がメインの記事ではないので、そのまま使ってしまいます（業務ではこんなことしませんよ）。

#include <sstream>
#include <nan.h>

NAN_METHOD(GetOsVersion)
{
	DWORD dwVersion = GetVersion();

	DWORD dwMajorVersion = (DWORD)(LOBYTE(LOWORD(dwVersion)));
	DWORD dwMinorVersion = (DWORD)(HIBYTE(LOWORD(dwVersion)));

	DWORD dwBuild = 0;
	if (dwVersion < 0x80000000)
	{
		dwBuild = (DWORD)(HIWORD(dwVersion));
	}

	std::stringstream ss;
	ss << dwMajorVersion << "." << dwMinorVersion << "." << dwBuild;

	info.GetReturnValue().Set(Nan::New<v8::String>(ss.str()).ToLocalChecked());
}

NAN_MODULE_INIT(init)
{
	Nan::SetMethod(target, "GetOsVersion", GetOsVersion);
}

NODE_MODULE(getosversion, init)

ビルドします。

node-gyp build

もろもろビルドされます。肝心のアドオンは、build/Release/getosversion.nodeとして生成されます。

│  binding.gyp
│
├─build
│  │  binding.sln
│  │  config.gypi
│  │  getosversion.vcxproj
│  │  getosversion.vcxproj.filters
│  │
│  └─Release
│      │  getosversion.exp
│      │  getosversion.iobj
│      │  getosversion.ipdb
│      │  getosversion.lib
│      │  getosversion.map
│      │  getosversion.node
│      │  getosversion.pdb
│      │
│      └─obj
│          └─getosversion
│              │  addon.obj
│              │  vc141.pdb
│              │  win_delay_load_hook.obj
│              │
│              └─getosversion.tlog
│                      ... （省略） ...
│
└─src
        addon.cpp

これを実際に動かしてみましょう。テスト用コードをこんな感じで書いてみます（test.js）。

var addon = require('./build/Release/getosversion');

var version = addon.GetOsVersion();

console.log(result);

nodeコマンドから実行してみると、それらしい値が取れました。

node test.js
10.0.16299

こんにちは、イメージ・マジックの岡野です。

当社は大半のサーバでUbuntuというLinuxのOSを使用しています。日本ではCentOSが良く使われていて入社された方がUbuntuに詳しくない事もある様ですので簡単に説明しようと思います。

読み方

Ubuntuはウブントゥやウブンツと呼ばれます。元々はズールー語の言葉で「他者への思いやり」の意味らしいです。なお、Ubuntu界隈では余り一般的でない単語が結構出てきます。”multiverse”（多元宇宙論）や”Artful Aardvark“（⁠巧妙なツチブタ）など。知らない人は何の事か分からないため（私も忘れやすいため時々検索して調べます）、外部からの印象は余り良くないんじゃないかと心配になります。

当社でUbuntuを使用した経緯

2012年頃までは当社でもCentOSやRed Hatを主に使用していました。ちょうど私が担当を引き継いだサーバでRed Hat Networkのアカウントが分からず、CentOSの方も古いパッケージ（ソフトウェア）がダウンロードできないなど、OS周りで辟易としていました。サーバリプレース時に良い評判を聞いていたUbuntuへ入れ替えた所、思っていた以上に良かったです。

メリット1 自動セキュリティアップデート

サーバの場合unattended-upgradesというパッケージを入れる必要がありますが、Ubuntuではほぼ全てのパッケージについてセキュリティアップデートが提供されています。脆弱性が見つかってから速い場合には4時間で対応が完了している事もあり（確かImageTragickの脆弱性の時、実際にはアップデート自体が実行されるまでのラグが存在する）助かっています。なお全て自動で任せていては対応が遅れるため「JVN脆弱性レポート」などのSNSをwatchして手動対応することもあります。

メリット2

他にも色々ありますが長くなって来たので省略します。

デメリット

/etc/に置く設定ファイルの場所などがCentOS等と異なるため、たまに別のOSを触ると戸惑います。

また続きを書きたいと思います。