Logical Rabbit.

さくらのVPS

PHP関連のメモ。

仕事でのメイン開発言語がPHPになったので。今までPHPをメインに使うことは無かったので(敢えて選択する理由が無かった)。お約束的な部分が色々分からんので自分用にメモ。

MySQL(MariaDB)に接続できないとき

  1. Socketが見つかっていない可能性を疑う
  2. php --ri mysqli とか php --ri pdo_mysql でパラメータをチェック
  3. Socketが設定されていない、もしくは正しくない場合は php.ini を確認
  4. そもそも何処の php.ini を見ているのか、と言う点を疑う
  5. 何処の php.ini を見ているかは、 php -i | grep php.ini とでもすれば分かる
    • 自分しか使わないマシンだったらとりま /etc/php.ini を設定していけば良いのだけど、ソースコンパイルしたPHP (php.7.1.1)だとそもそも <インストールディレクトリ>/lib/php.ini を見ていましたとさ。どっとはらい。
    • sudo ln -s /etc/php.ini <インストールディレクトリ>/lib/php.ini としたところ、/etc/php.ini を見るようになりました

さくらのクラウドでphp7環境を作るまで。

遅ればせながら「さくらのクラウド」にアカウントを作って、php7環境を構築して見たなど。

…そしてこの記事を下書きのまま3ヶ月ほど寝かせる事案… orz

「さくらのクラウド」のセットアップ

アカウントの作成

既にさくらインターネットの会員IDは取得済みです。そこから「さくらのクラウド」の利用を開始 →「さくらのクラウド」内にアカウントを作成 →「さくらのクラウド」内アカウント内にユーザーを作成、までやってようやくサーバーインスタンスが作れるようになります。何なんだこの多重構造(汗) 組織内で大規模に使うときは必要そうだけど、個人で使うには過剰ですね…。

「さくらのクラウド」の利用を開始するにあたっては電話認証も必要なので、ここは電話を掛けられる環境で作業する必要があります。

サーバーインスタンスの作成

まずデータセンターを選択します。同一スペックなら石狩のほうが安いっぽいです。都心部からの通信速度をシビアに要求するとか欲しい機能がリリースされているとかの理由で選択することになるでしょう。

次にサーバーインスタンスを…といきたいのですが、先にパケットフィルタを定義しておいたほうが手順的に楽です。

取り敢えずテンプレートを使用して、SSHは自宅IP(固定契約)、NTPはさくらインターネット提供のNTPサーバーのIPでフィルタを定義。私の場合自宅のほかもう1箇所よく使うIPがあるので、フィルタ定義後に[ルール] →[追加]でSSHの開放を1つ追加。この際追加位置に気をつけないと、最終行の「その他は全部拒否」の下に追加してしまい、つながらなくて首を捻ることになります(360°ほど捻った)。

本当はSSHポートも変更したほうがいいけど、IPのほうをガチガチに絞ったから、まぁ、いいかな、と。

そしてようやくサーバーインスタンスの定義です。「シンプルモード」だとパケットフィルタを選択できない様子? 「非シンプルモード」は1台だけちょっと作るには設定項目が過剰で面倒だけど。

OSはCentOS 7を選択。CPU/メモリはお試し環境ゆえ最小限で十分なのですが、最初はOSアップデートやコンパイルをやるので余裕を持たせておくと快適です。ただし後で戻すのを忘れると請求書が鬼と化しますが。フフフ、怖いか?

サーバー環境の構築

とりま、yum upgrade で最新環境にしておきます。あとsudoできる作業ユーザーを作ってrootは封印。

# useradd worker
# passwd worker
(パスワード入力)
# visudo
(worker をsudo可能ユーザーに)
# su - worker
[worker]$ ssh-keygen
(パスフレーズの設定などはお好みで)
[worker]$ vi .ssh/authorized_keys
(作業PCの公開鍵を登録)
[worker]$ chmod 600 .ssh/authorized_keys
[worker]$ exit
# vi /etc/ssh/sshd_config
(PermitRootLogin no を追記)
# systemctl restart sshd

以後はworkerユーザーで作業していきます。

php 7の導入

http://php.net/から最新版をダウンロード、適当な場所に展開します。

configureの設定は以下のようにしました。必要なライブラリの導入~configure実行~make test(+コメントアウトしているけどmake installとconfの配置)までをgistに記録してあります。実行前にprefixだけは確認してください。

ここまでで高負荷作業は終了するので、いったんサーバーをシャットダウン、プラン変更で実作業に必要な程度のCPU/メモリスペックへ変更しておくことをおススメします。

なお、4コアCPU+4GBメモリ+20GB SSDのセッティングでここまで約1時間といったところ。CPU使い切っていたようなので、もうちょいコア数増やした方が幸せかも(いや、コンパイラがちゃんとマルチコア対応しているなら、ですが…)。

php-fpmの設定

/etc/php-fpm.conf.default を /etc/php-fpm.conf へリネームし、設定を調整します。

  • daemonize は no にする (systemctl用のファイルでも指定されているが念のため)
  • include が /etc/php-fpm.d/*.conf となっていることを確認。

/etc/php-fpm.d/www.conf.default を www.conf または適当な *.conf にリネームします。

  • [www] は適宜変更
  • prefix は /var 等とする(ログが /var/log/ 直下に作成される)
  • user および group は apache に変更

複数のphp-fpmを稼動させる場合は、[www] の括弧内と listen のポート番号を適切に変更しましょう。

前述のgist公開バッチファイルでsystemd用のファイルは配置・設定されている筈なので、php-fpmを登録・起動します。

$ sudo systemctl enable php-pfm
$ sudo systemctl start php-fpm

Apache2の設定

さくらインターネット側のセキュリティ設定としてパケットフィルタを設定していますが、CentOS側にもfirewalldがあるので、ここでhttpを通すようにしておく必要があります。

$ firewall-cmd --list-all
public (default, active)
  interfaces: eth0
  sources: 
  services: dhcpv6-client ssh
  ports: 
  masquerade: no
  forward-ports: 
  icmp-blocks: 
  rich rules: 

$ sudo firewall-cmd --add-service http
success
$ sudo firewall-cmd --add-service http --permanent
success
$ firewall-cmd --list-all
public (default, active)
  interfaces: eth0
  sources: 
  services: dhcpv6-client http ssh
  ports: 
  masquerade: no
  forward-ports: 
  icmp-blocks: 
  rich rules: 

これでphp7を使うための環境が概ね整いました。

ConoHa VPS(1GB)で構築したOwnCloudサーバーをVPS(512MB)へ移設した。

1GBプランのバックアップイメージを512MBプランへ展開することはできない ようなので、結局手動で移設したなど。同期に失敗してデータ欠損しないかと動悸が止まりませぬ。

前提条件

現サーバー 新サーバー
ConoHaプラン(ともに東京リージョン) 1GBプラン(月額900円) 512MBプラン(月額630円)
メモリ1GB+SSD50GB メモリ512MB+SSD20GB
OwnCloud 8.1.5.2 9.1.1.3
OS(ConoHa製アプリケーションサーバーイメージ CentOS 6.7 (Final) CentOS 7.2.1511
データ格納 ConoHaオブジェクトストレージ


  • 現サーバー
    • ConoHa 東京リージョン・メモリ1GB+SSD50GB
    • OwnCloud 8.1.5.2
    • OS (ConoHa製アプリケーションサーバーイメージ) CentOS 6.7 (Final)
  • 新サーバー
    • ConoHa 東京リージョン・メモリ512MB+SSD20GB
    • OwnCloud 9.1.1.3
    • OS (ConoHa製アプリケーションサーバーイメージ) CentOS 7.2.1511

データ格納先はともにConoHaオブジェクトストレージ

手順

  1. ownCloudとの同期アプリを全て終了(自動起動もOFFにしておくとなお安心)
  2. 現サーバーでmysqlのフルダンプを取得
    $ mysqldump -u root -p owncloud_db |gzip -c > owncloud_db.dump.gz
  3. 新サーバー構築
    1. ConoHaコントロールパネルへログイン
    2. [サーバー追加]タブ
      • タイプ=VPS
      • メモリ=512MB
      • イメージタイプ=アプリケーション
      • アプリケーション=[その他] – ownCloud
      • ディスク容量=SSD20GB
      • その他の設定=適宜
    3. サーバー起動後、OSアップデート、作業ユーザー追加等々のセキュリティ対策は適宜。
  4. 現サーバーから新サーバーへmysqlのフルダンプをコピー
    $ scp owncloud_db.dump.gz  <新サーバーIP>:
  5. 現サーバーの /var/www/html/owncloud/config/config.php を新サーバーへコピー (注: このファイルはapacheオーナーのみ参照可になっているので、適当にセキュリティ突破すること)
    $ scp /var/www/html/owncloud/config/config.php <新サーバーIP>:
  6. 新サーバーへログイン
  7. mysqlのダンプを新サーバー上mysqlへロード
    $ zcat owncloud_db.dump.gz |mysql -u root -p -D owncloud_db
  8. config.php を /var/www/html/owncloud/config/ へ配置 (注: 既にファイルが存在するので、適宜バックアップ)
    $ sudo cp config.php /var/www/html/owncloud/config/config.php
  9. /var/www/html/owncloud/config/config.php の内容を編集
    1. trusted_domainsの配列内に現サーバーのhostname, IPアドレス等があるので、これを新サーバーのものへ変更
    2. overwrite.cli.url のドメイン名部分を現サーバーから新サーバーのものへ変更
    3. version を 現サーバー(8.1.5.2)から新サーバー(9.1.1.3)へ変更
    4. dbpasswordを新サーバーのmysqlサーバー、owncloud_userアカウントのものへ変更
  10. /var/www/html/owncloud/config/config.php のオーナーを user=apache, group=apacheに変更(なお、SELinuxはDisabledになっていました)
    $ sudo chown apache.apache  /var/www/html/owncloud/config/config.php
  11. apache2をリスタート
    $ sudo systemctl restart httpd
  12. 新サーバーのOwncloudへWebアクセスしてみる (成功していれば、セットアップ画面ではなく通常のログイン画面が表示されるはず)
    • このあたり、初回はプラグインのアップデートが始まる場合も
  13. 新サーバーのOwnCloud上にあるべきファイルがあることを確認
  14. 各OwnCloud同期アプリを起動
    1. 現サーバーの設定を削除し、新サーバーの設定を追加
    2. 同期が成功することをConoHaたんに祈る
  15. 現サーバーはこれにてお役御免ですので、最後にバックアップするなり、きれいに削除するなり、お好きに。

新サーバーへの残項目

  1. HTTPS化
  2. SELinuxがDisabledなので有効化したい
  3. PHPが5.6系なので7.x系にしたい
  4. ていうかこのPHP、PHP-fpmになってないよね?

新サーバー(512MBプラン)の注意点

  • やっぱりメモリに余裕ない感じ(以下は一通りの移設作業を終えた状態での計測)

    $ free —mega
    total used free shared buff/cache available
    Mem: 489 386 10 1 91 75
    Swap: 2047 121 1926
  • yum upgradeしたら最初のyumリポジトリへのアクセスが遅いように感じました。メモリでしょうか…?



ConoHaの既存プラン(メモリ1GB)のイメージを512MBプランでロードできなかった話。

Twitterのほうで呟いていたものを整理しました。「諦めて手動で移行しろ」←結論。

問題

ConoHaでメモリ512MB、SSD20GBプランが新設されました。既存の最安プラン(メモリ1GB、SSD50GB)より300円弱お安くなります。

以前からConoHaの1GBプランでOwnCloudのアプリケーションイメージをロードし、データ格納先としては同じくConoHaのオブジェクトストレージを使用していたのですが、この場合フロントエンドとなるVPS側はほとんどディスクを使用しません。ルートディレクトリからの実測で9GBくらいです。

これで50GBはもったいないし、とはいえリアルタイム同期させている都合上開発サーバー等にするのは扱いが面倒になるので、新プランのSSD20GBに縮小移行しようと思ったわけです。

で、VPS上で通常シャットダウン→ConoHaコントロールパネルで手動バックアップ→新しいVPSを512MBプランで選択、イメージタイプ:「保存イメージ」で作成しようと思ったのですが…イメージのリストに出てきません。

1GBプランで選択すると出てくるので、モノとしては存在する様子。というか以前別の目的でバックアップした開発環境VPSのイメージもリストに出てこない。

調査

挙動からして何かフィルタリングされているように見えたので、 ConoHa API 側からつつけば理由が分かるかと調査を開始。

以前開発した ConoHaでメール送信するツール でAPIアクセスの基本部分は出来ていたので、これを改造して利用しました。…というかこのアクセスライブラリ部分は切り分けて公開しましょうかね。OpenStackクライアントライブラリだとConoHa独自(?)のメールサーバー機能とか、使えない様子だし。

以前作ったコード に機能を追加。

    def list_image( self ):
        try:
            response = urlopen( urllib2.Request(
                urljoin( self.imageservice_endpoint(), '/v2/images' ),
                None,
                self.auth_headers
            ) )
            self.http_status = response.getcode()
            if self.success():
                infos = json.loads( response.read() )

                image_info = {}
                for info in infos['images']:
                    image_info[info['name']] = info

                response.close()

                return image_info
            else:
                response.close()
                return self.http_status
        except HTTPError as err:
            self.http_status = err.code
            return self.http_status
        else:
            response.close()

さらに呼び出し側も改造。

from conoha import ConoHa

import sys
import json

def exit_if_failure( conoha ):
    if not conoha.success():
        print( 'HTTP_STATUS: ' + str( conoha.http_status() ) )
        exit( 1 )


with open( sys.argv[1], 'r' ) as config_reader:
    config = json.loads( config_reader.read() )

conoha = ConoHa( config['identity_url'], config['user_agent'] )

connect_response = conoha.connect(
    config['username'], config['password'], config['tenant_id']
)
exit_if_failure( conoha )

image_list = conoha.list_image()
for name,image_info in image_list.items():
    if 'private' == image_info['visibility']:
        for key in image_info.keys():
            print( key + ':' + str(image_info[key]) )

        print( "\n" )

結果(だめでしたー)

APIの「 イメージ一覧を取得 」でチェックしてみると、「min_disk:50」となっています。

$ python list_image.py  config.json
container_format:ovf
min_ram:0
updated_at:2016-11-02T01:13:15Z
file:/v2/images/XXXXXXXXXX/file
owner:YYYYYYYYYY
id:XXXXXXXXXX
size:35246112768
self:/v2/images/XXXXXXXXXX
disk_format:qcow2
direct_url:file:///var/lib/glance/images/YYYYYYYYYY/XXXXXXXXXX
app:ownCloud-8-64bit
schema:/v2/schemas/image
status:active
tags:[]
hw_qemu_guest_agent:yes
visibility:private
min_disk:50
instance_uuid:ZZZZZZZZZZ
name:owncloud
checksum:ed2798eb07530bc79aa073c6e26f6e76
display_order:280
protected:False
os_type:lin
created_at:2016-11-02T01:08:03Z

(他のバックアップ情報は割愛、IDの類はマスク)

同じAPIから取得できる、ConoHa提供の既存OSテンプレートは概ね「min_disk:20」、一部のみ「min_disk:50」となっているので、どうやらこれが、イメージをロードするVPSが最低限持つべきディスク容量のようです。

…ただ、メモリ512MBプランでディスク容量を「SSD 220GB」にしても表示できないので、微妙に別の問題が絡んでいそうな気もします。

あと何故か実測9GBしか使用していないOwnCloudフロントエンドを手動バックアップすると32.83GBになるので、どちらにしてもこのままではSSD 20GBにロードすることはできないのですが。

min_diskを20に出来れば、あとはsizeが20GB以下ならロードできそうな気もするのですが、APIを見る限りこの情報を書き換える機能は無い様子なので、まあ詰みましたかね、と。

後はAPI側のVPS構築機能でメモリ512MBプラン+min_disk:50 のイメージを指定した場合にどこかでチェックされているか否か、というポイントがあるのですが…さて。

CentOS 7でBB無線ルータを組んだ時、無線LANから有線LANへWoL信号を飛ばしたい。

CentOSでイチからBB無線ルータを構築した際、ポートを越えてWoL(Wake on LAN)信号を飛ばす方法がようやく分かったのでメモ。…これでいいんだよ…ね?

前提条件

  • CentOS 7を2ポート有線LAN+無線LANのマザーボード(MSI製 Z97I AC)にインストールしてBBルータを構築
  • 有線LANの1つ目をインターネット側光ケーブルのOSUに接続、有線LANの2つ目と無線LANはイントラネットとして設定
  • イントラネットは基本的にdhcpdによるIP払い出し、主要なマシンのみIP固定
  • 有線LAN(イントラ)と無線LANは同一セグメント

方法

  1. /etc/dhcp/dhcpd.conf にて、DHCPにおいてMACアドレスとIPアドレスを固定で紐づける
  2. arp -s <IP address> <MAC address> としてARPテーブルにおいてMACアドレスとIPアドレスを固定で紐づける
  3. firewall-cmd --add-port=9/udpとしてWake on LANが使用するポート番号9(UDP)を解放する
  4. Wake on LANするときは対象マシンのIPアドレスとポート番号を指定して送信する(同一ポート上で実行する場合はブロードキャストモードで送信するか、IPアドレスとしてブロードキャストアドレスを指定して送信している筈)。

firewalldでMACアドレス指定の信号をポート間で通すとか、ブロードキャストを通すとかできれば済むような気はしていたのだけど、私の実力じゃ調べきれず、結局この方法で解決できたのでまあ良しとしたい。ポート9(UDP)がフル解放されている気がしないでもないが…うぅむ?

arpテーブルに気付いたのは、対象マシンを止めた直後であればWOLが通るので、もしかしてIPアドレスが誰に割り振られているのか分からなくて迷子になってるんぢゃね? と。マシン停止直後だとDHCPのリースとか生きてるだろうから、その辺を固定化してやればいいんぢゃね? という具合。

なおCentOS 7だとarpではなくip neighを使うべきらしいのだけど、Blogに纏めるにあたり試してみたもののこちらのコマンドでテーブルに追加する方法がうまくできず断念したなど。

本当はWake on LANのマジックパケットの仕組みとかから調べ始めていたのだけど(うまく通過できないから専用のサーバ立ててしまえばいいんじゃね、とか思った)、この辺りって軽くググった程度だとうまく見つかりませんね…? まあ結局無駄なこと調べていたっぽいけど。

ICS形式のカレンダーデータをJavaScriptでいじるときのメモ。

…これ、結局「Ical」と「Webcal」って何がどう違うんでしょうね…。何度調べてもよく分からん。ともあれ、扱うデータは「*.ics」なので「ICS形式」と呼んでおけば間違いなかろう、と。

某所で提案しようと下調べしていたのだけど、概ねめどが経ったところで募集状況を見に行くと既に終わっていたいつものパターンでしたとさ。まあフルタイム職が終盤に差し掛かってちょいと忙しかったしね…。というところで調べた成果の記録と供養など。

実行環境と使用ライブラリ

実行環境としてはNW.jsを使用して、Node.jsで実装しています。NW.jsはJavaScriptとHTMLとCSSでお手軽に書けるうえ、JavaScriptなのでWebアクセス系は楽々扱え、しかも実行バイナリはWindows、Mac OS X、Linuxと幅広く対応できるのがとても良いと思います。

コンパイラ系言語を使わなくて良いというより、クロスプラットフォームが簡単に実現できる、モノによってはWebアプリケーション化まで視野に入れることができるという点が気に入っています。

でも最近Go言語も気になっているのだけど、あっちとの比較はどんなもんだろう…?

もとい。

使用ライブラリは icalパッケージ。加えて、画面制御系としてjQueryも使います。

実装

icalパッケージでWeb上のICS形式読み取りとオブジェクト化は容易に実現できます。

問題はICSから読み取ったイベント情報が「繰り返し」だった場合。

例えばGoogleカレンダーで「2016年1月1日から12月30日まで、毎週金曜日に「今日は金曜日!」とセットした場合、ICSデータには「毎週金曜日に「今日は金曜日!」と追加されるのではなく、開始が1月1日、終了が12月30日、かつ「週ごとの繰り返しで金曜日のみ有効」というルールが付与されたイベントが1件だけ追加されます。

このようなイベントをicalパッケージで処理した場合、rruleプロパティ内に繰り返し情報が格納されます。さらに rrule.all() とすると具体的な日付に展開したArrayが返ってきますので、これを使用することで他のイベントと同じように日付として扱うことが可能になります。

(以下のCALENDAR_URLで指定しているカレンダーは、非公開(ICSのURLを知っている人のみ参照可)として実際に置いてあります。

var ICal = require( 'ical' );

var CALENDAR_URL =
  'https://calendar.google.com/calendar/ical/u78uo80t8b784ojbbf265tpkv4%40group.calendar.google.com/private-8d07e17f65ddac761f8cf190f3e69fee/basic.ics';

ICal.fromURL( CALENDAR_URL, {}, function( error, data ) {
  if( error ) {
    console.log( error );
  }
  else {
    var keys = Object.keys( data ).sort();
    keys.forEach( function( key ) {
      var friday = data[key];
      if( friday.rrule ) {
        friday.rrule.all().forEach( function( realDay ) {
          console.log( [
            friday.summary, realDay.toLocaleDateString()
          ].join( ' ' ) );
        } );
      }
    } );
  }
} );

なお、rruleがあるデータの場合なぜかstart, endにはtoLocaleDateString()等が使用可能なデータが入っていませんので注意。

購入検討中の書籍メモ (2016.09)

…という名目のアフィリエイトリンク集。実際に買うか、いつ買うかは未定だけど気になっている本。全て電子版あり。実際に買ってレビューする気になったら別記事に分けると思われ。

ユーザーストーリーマッピング

実装技術というよりその1段上、ハンドリングとかディレクション系の本と理解。個人事業もしくは零細企業規模の職場でシステム開発をすると、どうしても発注主の意図を汲みつつ方向性をまとめたり調整したりする必要が発生するので、たぶんまとめて全体を把握した後、後々まで読み返すような使い方になるんじゃないかなー、と期待してます。

未購入(物理書店で軽く内容把握)、AmazonのほかオライリーのEbook Storeで販売中。

開眼!JavaScript

発行はかなり前なんだけどそういえば未読だったし、JavaScriptはどうしても「なんとなく」で使って覚えてしまっている部分が多いので、たまに基本を読み返すのに良いかな、と思った次第。ページ数も少なく、気になるところだけ流し読みするのにも良さそうだし。詳細は「JavaScript」とかをあたることにして、全体の復習はこちらで随時行う方向で。

未購入(物理書店で軽く内容把握)、AmazonのほかオライリーのEbook Storeで販売中。

現場でかならず使われているjQueryデザインのメソッド

個人事業やるようになって、やはりjQuery等でお手軽かつ見目良くWebサイト開発する需要は高いなぁと思うと同時に、自分自身のデザインバリエーションが少ないことを痛感してます。なにせ今まで「動けばよい」の世界というか「チェックマトリックスでテストできることが最優先のデザイン」の世界だったので「画面幅によってデザインが変わる」ような一般的な設計とは縁遠かったわけで(設計書どおりのデザイン配置にならないのはバグなので、画面幅を強制固定するのが正道、TABLEレイアウトこそ至高、の世界)。

デザイン(動き)さえ分かれば技術的には自分で考えて実装できると思うのですが、まあ使えるスペアタイヤがそこに転がっているのに使わない手も無いだろうと。

ということでサンプル集的な用途を期待。Webで色々見つけてくるのも、技術検証とか著作権確認とかが面倒になってきたから。

未購入(物理書店で軽く内容把握)、Amazon kindle版あり。

さくらのVPSをOS更新したい…という話。

現状このWebサイト等を公開運用している「さくらのVPS」は、OSがCentOS6.x系。そろそろCentOS7.xにしたい。あとリバースプロキシとかも一度再設定したいところ。

OS更新は面倒くさいし、どうせ6.xから7.xは色々変わるのでOS再インストールからやってしまいたいのだけど、いかんせんWebサイトを公開運用しているので長いこと止めるわけにもいかない。どこかに仮サーバーを設置しないと。

で、仮サーバーとして「さくらのVPS」を使うか「さくらのクラウド」を使うか、はたまた「ConoHa」に逃げるか。できれば同じさくらインターネット上のサービスを使ったほうが、仮移設時の問題が少ないように思う。「さくらのクラウド」にはVPSのイメージを元にクラウド側を構築する機能があるので、先ずこれで仮移設してしまえばよさげ。あとはDNS切り替えの問題とか。

問題は料金。

  • 「さくらのVPS」は初期費用がそこそこかかる。現在と同一プランだと月額972円+初期費用1,620円(合計2,592円)
  • 「さくらのクラウド」は初期費用は無いけど利用料金がそこそこかかる。VPSと同等で試算すると、14日利用で2,478円、月額3,132円…の筈。これ単一サーバー稼動の場合はネットワーク等のオプション要らなかったよな…?
  • 参考までに「ConoHa」は初期費用なし、月額900円または時間あたり1.3円。14日利用だと1.3円×24時間×14日=436.8円。このはたんサイキョー。

なお「さくらのVPS」は現在「2週間無料お試し」があり、まあ今回用途だと2週間もあれば用は済むので「お試し」だと言い張れば無料で使うこともできる。が、お試しではないし色々お世話になっているところなので、きちんと支払いをしておきたい。

無料お試し期間中でも決済をすれば支払いはできる筈なのだけど、"お試し期間中であっても、会員メニューより「本登録(決済)」いただくと、すぐに本サービスを開始することができます。なお、すぐに本サービスを開始いただいた場合でも、2週間は無料でご利用いただけます。"とあり、これ決済して2週間以内に解約するとどうなるんだろう…的な疑問も。

また"さくらのVPSの最低利用期間は3ヶ月"なので、2週間程度の利用目的でも3ヶ月分費用が発生してしまう。3ヶ月+初期費用だと4,536円。これを考えると「さくらのクラウド」で1ヶ月利用したほうが良いか。

「さくらのVPS」をもう1台契約、新契約のほうに移設後DNS切り替え、旧契約を解約という方法もあるのだけど、現契約は年間契約にしているため次の更新は2017年5月末…。今解約するのはもったいない。

結論としては、「さくらのクラウド」を試しに使いつつ1ヶ月以内でVPS側を再セットアップ、というところかな。VPSをそこそこ長く使っているとこの手の問題は出て来る筈なので、何か便利なサービスがあっても良いと思う今日この頃。

Google Apps Scriptで開発するときの備忘録。

最近クラウドワークスでのお仕事でいくつか Google Apps Script を使用したのだけど、なかなか使える良い子であると同時に癖もある奴なのでいつも使うパターンをメモするなど。

スクリプトの実行時間は1回あたり6分

仕様的には Quotas for Google Services を参照。

細かい処理をちょいちょいとこなす程度であれば気にする必要はないのだけど、大量のファイルとかを扱い始めるとハマる。というかハマッた。

対策としては「6分以内に終わらせる」もしくは「6分超えそうだったら一度中断し、改めて再開させる(中断・再開が可能なつくりにする)」の2パターン。ただこの制限値に引っかかるような処理をさせると結構動きがトロいのも分かるので、第3のパターンとして「Googleの外でやる(普通のサーバー上でGoogle APIを呼び出す)」を考えに入れておくべきなのかと思った。

処理を一度中断し、自動で再開させるのは Properties + Trigger 、ところにより JSON

いくつかググって、最終的には Google Apps Scriptで5分の壁(タイムアウト)を突破するを参考にしつつ自分なりのパターンを作ることにしました。

  • スクリプトの処理開始時刻を保存しておき、開始後何分経ったかを随時チェック

  • 開始後6分を超過する前に十分な余裕をもって中断処理に入る

  • スクリプトの処理に必要なデータは Properties Service に格納する

  • ただし Properties はString value しか扱えないので、構造化データなどを格納したい場合は JSONフォーマットに変換して格納する

    • Propertiesへ格納する際は JSON.stringify()
    • Propertiesから復帰する際はJSON.parse()

    なお当初Base64を使おうとしていたのは秘密だ(待て)

  • スクリプトを終了後自動的に再開させるのは Script ServiceClockTriggerBuilder クラス。

  • 前述のBlogでも言及されていたし実際うまくいかなかったのだけど、Triggerで「after(durationMilliseconds)」があるくせにセットしてもちゃんと発動しない。…というか発動するのかもしれないけど「(plus or minus 15 minutes)」などとのんびりしたことを言われてしまっては使うわけにはいかんがな。せめて単位をsecondsにしてくれ…。

    everyMinutes(n) で毎分起動→起動後に多重起動防止のためトリガーを削除 のパターンでいきませぅ。

    ただ、ここはむしろトリガー追加+削除を繰り返すより、別途キューを用意しておき、毎分キュー確認→なにかあれば実行、何もなければ休眠、のほうがスマートな予感。

参考資料など。まー私が使ってるのはオライリーが販売しているPDF版ですがねハハハ(これはこれでよりによって「String」の項にしおりが設定されていないという痛恨のバグがある)。

DELLの25インチモニター U2515H を購入した。

購入してから10日、概ね安定してきたようなのでレビューを書いてみるなど。結論としては、もう一枚買っても良いかもなー、的な。

ディスプレイ モニター U2515H。通称ゆーちゃん(違う)

スペックとしては25インチIPSノングレア、WQHD(2560x1440)、sRGB99%です。これで5万円弱なのでかなり安い印象。27インチフルHD超になると10万円くらい見ておかないといけないので、ちょっと二の足を踏んでいたところなのでした。

非DELLの汎用モニターアームで使っていますが、標準装備のディスプレイスタンドもかなり使いやすそうではありました。ただ今の机環境だと、机にスタンドで置いてしまうと画面と顔との距離が近すぎてしまうので…。

解像度は十分です。Teraterm + tmuxで使っていますが、フォントサイズ14ptで縦70行(プラスviのステータス行+tmuxのステータス行)表示できます。フォント10ptだと流石に少し見づらいか。また、Windowsキー+横キーで画面半分に寄せても、tmuxの縦2列で77桁出てます。普段はフル画面縦2列を基本にしていますが。

ハード面の機能も使い勝手が良いです。まず背面のディスプレイスタンドは工具なしで付け外しが可能。ツメで止まっているので、斜めに差し入れて垂直に戻すと自動的にロックされ、外すときはボタンを押して斜めにすれば外れます。

スタンドを止める場所は一段くぼんでいて、その中にVESAマウントのネジ穴が、ネジ付で収まっています。ネジを外してモニターアームを取り付ければ完了。しかしアーム側に付いていたネジが余ったぞ(汗) 写真を見る限りDELL純正のモニターアームならばスタンドと同様に工具レスで取り付け・取り外しできるようなので、そちらを買ったほうがまとまりが良かったかも知れませぬ。うちには既にモニターアームが3つ転がっていたので、純正品を買うのは止めたのですが…。

入力端子はHDMI×2、DisplayPort×1、mini DisplayPort×1、その他USB 3.0 HUBが付いています。D-SUBとかDVIが無いのはまあ致し方なし。DP-MiniDPのケーブルが同梱されているので、DisplayPort対応のビデオカードだと最強の組み合わせかもですね。うちはHDMI出力なのでHDMIに入れていますが。

当初モニタがノイズ出まくったりブラックアウトで点滅したり、特にMikuMikuDanceとかをフル画面で出すと頻繁にブラックアウトするのでビデオカードへの高負荷が原因、買い替えかなぁと思っていたのですが、ビデオドライバを最新に更新し、HDMIも切り替え機を通さず直結したら安定稼動になりました。おそらく最大の原因はHDMI切り替え機と思われ。先代はHDMIが1ポートだけだったので切り替え機を通していたけど、今回は2ポートあるので切り替え機が使えなくても特に困ることは無いでしょう。

なおビデオカードはNVIDIA GeForce GTX750 DDR5 2GBです。これをHDMI(WQHD)、DVI(UXGA)、D-SUB(フルHD)の3画面出力で使用中。

DELLが基本的にネット直販で現物を見ることが出来ないのと、公式ストアでも海外からの発送になって衝動買いに向かないところなのですが、Amazonにプライム対応即納品があったので(しかも公式ストアより安い)、こちらでポチることにしました(事前に横浜ヨドバシカメラのDELL売り場行ったのだけど、該当品が無かった…)。