iPhone SE 使用開始

今月末で電波が止まるワイモバイル (旧イーモバイル) の携帯電話を使ってきたのだが、iPhone SE 一括1円という巻き取りで移行した。
届いた iPhone SE はバッテリーが完全に空っぽになっていて、そのため初期設定に少し手間取ることになった。
早い話、時計が盛大にずれているのでそれを直して再起動する必要があった。

それに気づくまでああでもないこうでもないと情報を探し回る羽目に。
初期設定の Apple ID ログインがまずできない。
Safari でアクセスする HTTPS サイトが片っ端から証明書エラー。
iOS 11 にアップグレードすれば直るかと思いきや、そのダウンロードさえもコケる有様。

設定項目を片っ端から見ていると、時計が半年前。諸悪の根源はこいつか!!


昨今の5インチスマートフォンよりやや細身で、片手で使うにはやはりこのサイズが使いやすい。
普段使っている SIM フリー安物 Android 端末 (MVNO) と比べると、確かに iPhone の出来は良い。
前に使ったことがある iPhone 4s の頃と違って、ちゃんとテザリングもできるし。
しかし ATOK Passport に入っているのに iOS 版 ATOK を別途購入しなくてはならないのは Apple のせいで、しかたないから買ったけれども腹立たしい。


初詣 (平成30年)

昨年と同じく、終電での移動。

前回も列が短いと感じたが、今回はさらに短くなっていた。
お守りもらっておみくじ引いて (大吉)、前回より5~10分早いぐらい。

初詣の個人的なお目当て、ふかしてるじゃがバターは、なんと1軒しか見当たらない。絶滅危惧種。
あと串焼き食べたり。
境内で「動物保護」とか言って募金活動してる男がいたが、あれは許可とってんのかねえ。胡散臭いのでお断り。

始発までeワールド府中店で3時間パック。
PC に Office 2007 が入ってるんだが、これ延長サポート終わったんだよね。
近辺にいびきのうるささを競うようにズゴゴゴとやかましい客が複数いて参った。

始発で帰った時点で眠気が激しく、初日の出は行かないことに。

10億円引換券の予定が300円引換券に化けたり色々沈んで去年はアレだった。今年は良い年になるといいなあ。


Debian stretch で Pleroma インスタンスを立ててみた

Mastodon より軽いと評判の Pleroma インスタンスを立ててみた。
確かに消費メモリはかなり少ない。
Mastodon はメモリ 1GB の VPS ではメモリ不足でスラッシングホーダイだったが、Pleroma はメモリ 512MB の VPS で Pleroma 自体が 14% 程度のメモリ消費。
PostgreSQL や httpd の消費分を含めても、メモリ 256MB の VPS で十分動作可能だと思う[1]

公式のインストール手順だと引っかかるところがいくつかあったのでメモを残しておく。


早い話:

  • PostgresSQL のユーザー pleroma を作る時に CREATEDB をつける。
  • mix ecto.create と mix ecto.migrate の間で、PostgreSQL のスーパーユーザーで DB に CREATE EXTENSION citext; する。
  • 画像が http://localhost:4000/ 下になるのは、mod_substitute (Apache の場合) で書き換える。

Erlang は Debian にも収録されているが、公式の説明通り upstream のリポジトリを使う必要がある。
git も当然必要だが、公式の説明には書かれていないので入れる。

% wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb
% sudo dpkg -i erlang-solutions_1.0_all.deb
% sudo apt update
% sudo apt install esl-erlang elixir build-essential git
% sudo useradd -d /home/pleroma pleroma
% su pleroma
% cd
% git clone https://git.pleroma.social/pleroma/pleroma.git
% cd pleroma
% mix deps.get

PostgreSQL のユーザー pleroma に CREATEDB をつけてやらないとコケるのでつける。
たぶん開発者は postgres ユーザー権限で作業してるんだろうなあ。
公式説明では \c pleroma_dev から始めてるけど、そもそもデータベース pleroma_dev は後の mix ecto.create で作るから、この時点では存在しない。

% sudo -u postgres psql
CREATE USER pleroma CREATEDB;
ALTER USER pleroma WITH ENCRYPTED PASSWORD 'パスワード';
\q
% exit

config/dev.secret.exs を編集する。
公式の説明だと dev.exs をコピーして編集することになっている。
これはバージョンアップで dev.exs が更新される場合があることによるのかな。
標準だと postgres ユーザー権限を使うように書かれているので、ここはさっき作った DB ユーザーに変更する必要がある。説明とデフォルト設定にズレがある。

% mix ecto.create

公式説明だと && mix ecto.migrate してるけど、その前にやることがある。
mix ecto.migrate で citext 拡張が入ってなければ入れることになっているのだが、PostgreSQL のユーザー pleroma には拡張の権限がないので CREATE EXTENSION citext; に失敗する。

% sudo -u postgres psql
\c pleroma_dev
CREATE EXTENSION citext;
\q

これでようやく mix ecto.migrate できる。

% mix ecto.migrate

公式の説明では Nginx でリバースプロキシしているが、私は Apache を使っているので Apache でのやり方を。

/etc/apache2/sites-available/pleroma.example.com.conf を作成。

<VirtualHost *:80>
	ServerName	pleroma.example.com
	DocumentRoot	/home/pleroma/www
#	Redirect	permanent	/	https://pleroma.example.com/
</VirtualHost>

#<VirtualHost *:443>
#	ServerName	pleroma.example.com
#	SSLEngine	On
#	SSLCertificateFile	/etc/letsencrypt/live/pleroma.example.com/cert.pem
#	SSLCertificateKeyFile	/etc/letsencrypt/live/pleroma.example.com/privkey.pem
#	SSLCertificateChainFile	/etc/letsencrypt/live/pleroma.example.com/chain.pem
#	DocumentRoot	/home/pleroma/www
#	ProxyPassMatch	^/(.well-known/acme-challenge) !
#	ProxyPass	/	http://localhost:4000/
#	AddOutputFilterByType	SUBSTITUTE \
#		text/html \
#		application/json \
#		application/javascript \
#		text/javascript \
#		text/css
#	Substitute "s|http://localhost:4000/|https://pleroma.example.com/|"
#</VirtualHost>

これで Let’s Encrypt の証明書ができたらコメントアウト部分を有効にする。

アップロードしたアバター画像などが http://localhost:4000/ 下にあるような html が出力されるので、これを mod_substitute で書き換えている。


(2017/11/20 追記)

ITmedia の記事で作者が「月額2.5ドルの仮想サーバで動かしている人もいます」と言っているが、私は年額 2.99 USD の VPS で動かしている(笑)。

  1. さすがに 128MB では PostgreSQL と Apache を起動した時点でメモリの残りが 30MB を割ったので無理だと判断した。 []

nazwa.pl の激安 VPS を契約してみた

nazwa.pl というポーランドのホスティング業者があって、初回支払い分限定割引で目玉が飛び出るぐらい激安の VPS を出していたので思わず契約。

カタログスペックはこんな感じ。

  • 11.88 PLN / 年 (初年度のみの価格。このほか VAT やカード決済手数料が追加される)
  • メモリ 4GB
  • ディスク 25GB NVMe
  • 最大転送量 100GB / 日
  • 場所 ポーランド (ping rtt 270-300ms 前後)
  • KVM

サイトはポーランド語のみで作られている。読めないので Google 翻訳に頼りまくってなんとか契約した感じ。

契約時点でポーランドの通貨ズウォティ (PLN) は約31.15円。
VAT やらカード決済手数料やらが追加されるが、諸々含めてトータル500円程度。
PayPal に対応していないので、日本から利用するには事実上クレジットカードのみ。
普段使っているカードで支払うのにいささか不安を覚えてジャパンネット銀行のカードレス VISA デビットで支払ったところ、513円の引落だった。

513円でメモリ 4GB の KVM VPS が1年使えるって、これはかなりすごい話だ。
この価格は初回分のみで、通常価格は月 9.99 PLN。通常価格でも月500円未満なのでかなり安い。国内業者の8割引。

注意点としては、こんなところか。

  • ポーランド語なので翻訳に頼らなくてはならない
  • カートに入れた時点で有料オプションの DirectAdmin が選択された状態になっている (ので外す)

支払い完了から47時間強で開通。
身分証明書の提示を要求される事例もあるようだが、私の場合は要求されなかった。

さすがに経路が太平洋と大西洋を横断していくので ping rtt の数字が大きく、ssh は快適とはいえないが、動作自体は軽快。
vpsRus から Mastodon インスタンスを移転したら早くなった。


Debian stretch で Mastodon サーバーを立て直した

前回、Ubuntu で Mastodon サーバーを立てたのだが、さすがにメモリが 1GB では明らかに不足していて、Mastodon のバージョンアップに際して assets:precompile するだけで30分以上かかるという有様だった。
その上 CloudAtCost が長期間ダウンしたため、もう少しまともな環境で立て直すことに。

vpsRus の VPS で、カタログスペックはこんな感じ。

  • 2.5 USD / 月
  • CPU 2仮想コア
  • メモリ 2GB (vswap 2GB)
  • HDD 200GB
  • 月間転送量 1TB
  • 場所 イリノイ州シカゴ (ping rtt 200ms 前後)
  • OpenVZ

国内業者と比べると 1/4 以下のお値段。
シカゴにしては ping rtt がちょっと遅い。あとディスク I/O が結構遅い。たぶんユーザー詰め込んでるからだが、こんな値段でこれだけメモリ使えるなら我慢できる。


というわけで Mastodon を入れていく。
前回と比べるとプロダクションガイドも大幅に更新されており、それに従っていけば問題ない。
今回は#385に従うが、Nginx ではなく Apache を使う。
前回は rbenv を使わなかったが、今回は使う。


早い話:

  • redis-server と PostgreSQL がすんなりいかない。
  • redis-server は apt でのインストール時にエラーが出るので、/etc/systemd/system/redis.service の「ReadWriteDirectories=-/var/run/redis」から「/var」を削除して apt -f install。
  • PostgreSQL はデータベース template1 を encoding=’UTF8′ で作り直す。

node.js、yarn のリポジトリを追加、インストールしていく。プロダクションガイドは Ubuntu 16.04 ベースで書かれているが、Debian stretch も apt はプロダクションガイド通りに実行していい。

ただ、redis-server のインストールでエラーが出る。
これは /var/run が /run へのシンボリックリンクであることによるものらしく、/etc/systemd/system/redis.service の次の行を修正すればいい。

ReadWriteDirectories=-/var/run/redis

ReadWriteDirectories=-/run/redis
% sudo apt -t install

PostgreSQL の template1 が SQL_ASCII なのでうまくいかない。なので template1 を UTF8 で作り直す。

% sudo -u postgres psql
update pg_database set datistemplate=false where datname='template1';
drop database template1;
create database template1 with template='template0' encoding='UTF8';
update pg_database set datistemplate=true where datname='template1';
\q

バッドノウハウ!


Ubuntu 16.04 で Mastodon インスタンスを立ててみた

前回、Mastodon がメモリ食いらしいので代わりに GNU social インスタンスを立ててみたのだが、それでも一応 Mastodon も触ってみたくなったので CloudAtCost の Developer Cloud Pro 1 (メモリ 512MB、ストレージ 10GB) を2台持っているのを1台にまとめてインスタンスを立ててみることにした。

まとめるとこんな感じ:

  • なるべく APT で済ませる (基本方針)。
  • rbenv は使わない。Ubuntu 収録の Ruby 2.3.1 でいく。
  • なぜか bundle install 通らないのは Gemfile いじって無理矢理。

あ、Docker 使うのが普通みたいだけど使ってない。


基本方針は「なるべく APT で済ませる」だ。アップデートチャネルが多くなると面倒なので。
当初 Debian jessie で構築を進めていたが、Ruby 2.1 ではさすがに古くてどうにもならず、当然ながら ruby-build も古くて rbenv で Ruby 2.4.1 を入れることができず、rbenv 関係全部 git で入れる羽目になって基本方針とかけ離れてきたので中止。
なお CloudAtCost の Ubuntu イメージは 14.04 しかないので、まず最初に do-release-upgrade で 16.04 にした。

ベースは Mastodon のプロダクションガイドに従うが、APT で代替できるものは APT にする。
その際、PPA もどんどん使う。

以下、プロダクションガイドの記述順に沿って書いていく。


プロダクションガイドではユーザー mastodon、ホームディレクトリ /home/mastodon を使うことを前提としているのでユーザーを作っておく。違うものを使う場合は適宜読み替える。

Nginx 関係は後に回す。


まずは Node.js。プロダクションガイドの手順ではこうなっている。

sudo apt-get install imagemagick ffmpeg libpq-dev libxml2-dev libxslt1-dev file git curl g++ libprotobuf-dev protobuf-compiler
curl -sL https://deb.nodesource.com/setup_6.x | sudo bash -
sudo apt-get install nodejs
sudo npm install -g yarn

1行目はそのままでいい。

2、3行目もそのまま。
Ubuntu 16.04 では Node.js 4.2.6 が収録されているが、後で必要になる browserify の導入には 4.6 以降が要求されるので、素直に 6.x を入れてしまう。

4行目は yarn の apt-line 追加に変更する。

wget -qO- https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
sudo apt update
sudo apt install yarn

Redis と PostgreSQL はプロダクションガイドの通り。


次は Rbenv だが、Ubuntu 16.04 が Ruby 2.3.1 収録のところ、Mastodon は Ruby 2.4.1 を要求している。
しかし Gemfile を見ると 2.3.0 以上 2.5.0 未満となっているのでこのままいく。
つまり、rbenv は入れない!

sudo apt install ruby bundler

ユーザー mastodon に su しての作業は、git checkout まではプロダクションガイド通り。

cd ~
git clone https://github.com/tootsuite/mastodon.git live
cd live
git checkout $(git tag | tail -n 1)

ここからは違ってくる。
プロダクションガイドでは次のようになっている。

gem install bundler
bundle install --deployment --without development test
yarn install --pure-lockfile

bundler はさっき apt で入れたので1行目は除外。


.env.production は DB がローカルの場合、DB_HOST に localhost とか書くと ident 認証がコケるので、空にする必要がある。
こんな感じに。

REDIS_HOST=localhost
REDIS_PORT=6379
# REDIS_DB=0
DB_HOST=
DB_USER=mastodon
DB_NAME=mastodon
DB_PASS=
DB_PORT=5432

そしてセットアップ。

RAILS_ENV=production bundle exec rails db:setup

これはプロダクションガイド通りではあるが、Ruby のバージョンチェックで引っかかる。
/home/mastodon/live/Gemfile の4行目だ。

ruby '>= 2.3.0', '< 2.5.0'

とあり、2.3.1 が入っているのだから問題ないはずなのだが。
PPA で 2.4.1 を入れた状態でも引っかかる有様だったので、行頭に # をねじ込みコメントアウトして無理矢理いく。

次に進む前に browserify を入れる。これだけは APT 管理できない。
node-browserify-lite では代用できなかった。

yarn add browserify

そして次に進む。

RAILS_ENV=production bundle exec rails assets:precompile

その次は systemd 周りの前に、Nginx と Let’s Encrypt を済ませる。


Nginx のインストール。

sudo apt install nginx

プロダクションガイド記載の設定は Nginx 全体のものではなくサイト設定なので、/etc/nginx/sites-available/mastodon とかファイルを作ってそこに書く。流用でいいが、一応ググって基本的な理解をしておいた方がいいとは思う。

流用の場合、基本的にすべて HTTPS でのアクセスになる。
HTTP は Let’s Encrypt のドメイン確認のみに使い、それ以外は HTTPS にリダイレクトされる。
SSL 関係の設定は Mozilla SSL Configuration Generator を参考に詰めることをおすすめする[1]
以下、流用ベースで書いていく。

なお HTTP の方にも

  root /home/mastodon/live/public;

を書いておかないと certbot がコケる。

sites-available にあるだけではもちろん動かないので、sites-enabled にシンボリックリンクを張る。

sudo ln -s /etc/nginx/sites-available/mastodon /etc/nginx/sites-enabled/

certbot で Let’s Encrypt の証明書を導入しておく。

まずは certbot の導入から。

sudo add-apt-repository ppa:certbot/certbot
sudo apt update
sudo apt install certbot

/etc/ssl/certs/dhparam.pem も作っておく。

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

一時的に /etc/nginx/sites-available/mastodon の

  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

は行頭 # でコメントアウトしておく。でないと今はまだ証明書も鍵もないので、Nginx がエラーを吐く。

sudo systemctl reload nginx
sudo certbot certonly --webroot -w /home/mastodon/live/public -d example.com -m admin@example.com

証明書ができたら、/etc/nginx/sites-available/mastodon の先ほどコメントアウトした部分を戻して nginx を reload。


プロダクションガイドの続きに戻って systemd 周り。
基本的にはプロダクションガイドの記述をそのままコピペでファイルを作っていけばいいのだが、rbenv を使っていないので /home/mastodon/.rbenv_shims/bundle はない。
/usr/bin/bundle を使う。

ExecStart=/home/mastodon/.rbenv/shims/bundle exec puma -C config/puma.rb

↑これをこうする↓。

ExecStart=/usr/bin/bundle exec puma -C config/puma.rb

crontab も同様に。


メモリ 1GB ではかなりカツカツという事前情報は正しく、ruby2.3 が4プロセスで合計 700MB 近く食っている。

以下はメモリ 128MB や 64MB といった極小 VPS でこそ役に立つものの 1GB 積んでると誤差レベルのメモリ節約にしかならないことだが、一応やっておく。

  • syslog は rsyslog から inetutils-syslogd に差し替える。
  • ssh サーバーは openssh-server から dropbear に差し替える。
  1. 流用そのままだと SSL Server Test スコア A- だが、少し詰めるだけで A+ になる。 []

シェルが使えない共有レンタルサーバーで GNU social インスタンスを立ててみた

忙しい人向けの結論:
Softaculous ついてる共有レンタルサーバーで Qvitter プラグイン入れるのが楽。
Softaculous でドメインの / に GNU social をインストールし、FTP 等で Qvitter を入れる。


先月あたり Mastodon が流行って、自分でもインスタンスを立ててみようと思っていたのだが、かなりメモリを食うようで躊躇していた。メモリ 1GB の VPS でも swap を使い始めるほどだと。
Mastodon は GNU social と互換性があると紹介されていたので、GNU social の方をチェックしてみると、ぶっちゃけ LAMP 環境で動く。
GNU social なら VPS ですらなく、いわゆる共有レンタルサーバーでもいけるのではないか? と思ったのが始まり。

しかし蓋を開けてみると GNU social もやはり設置先サーバーでシェルが使えることが前提になりそうだ。
インストールまでは問題ない。git がなくても master ブランチの zip をダウンロードして展開すればいい。
問題はバージョンアップで、1.1.x から 1.2.x へのアップグレード手順の説明 (UPGRADE) では script/upgrade.php をコマンドラインで実行せよとある。
試しにブラウザーからアクセスしたら、

This script must be run from the command line

と表示されて動作しない。
将来のバージョンアップでも同じ手順を踏むと考えると、インストールまではシェルが使えなくても大丈夫だが、バージョンアップ時にシェルが必要になるわけだ。

つまり、シェルが使えない大多数の共有レンタルサーバーでは GNU social インスタンスを長期的に利用することは難しい、ということになる。


Softaculous という各種ウェブ・アプリケーション簡単インストーラーがあって、特に海外の cPanel 採用の共有レンタルサーバーではこれが導入されていることが多い。
これは何ができるかというと、コントロールパネルから選んで最低限の設定内容をフォームに入力していくだけで、対応アプリケーションをインストールできる。WordPress や Joomla やその他かなりの数のアプリケーションに対応している (対応リスト)。
バージョンアップがあった際の更新もコントロールパネル上で行うことができる。

そして Softaculous で簡単インストールできるものの中に、GNU social がある。
これなら将来のバージョンアップ時も Softaculous に更新させればシェルなしでいけるのではないか。


Softaculous で GNU social をインストールする際の注意点としては、インストール先ディレクトリが標準では「gnu」になっているのを空にしておくこと。
つまり https://example.com/gnu/ といったサブディレクトリで使うのではなく、https://example.com/ といったドメイン直下で使う。
https://gs.example.com/ といったサブドメインで使うのも良いかも知れない。

これは後述する Qvitter プラグインがドメイン直下へのインストールを要求するためだ。


GNU social で日本語表示を使うためには、locale/ja/LC_MESSAGES/statusnet.po や plugins/*/locale/ja/LC_MESSAGES/*.po を gettext のユーティリティ msgfmt で .mo に変換してアップロードする必要がある。
これはプログラミングをやる人以外には結構ハードルが高いと思われる。そもそも一般人の Windows PC に gettext なんか入っているわけがない。しかも変換すべきファイルが分散しているので make を使わないと面倒くさすぎるし、make もまた一般人の Windows PC には入っていない。

さらに別件だが GNU social の標準画面構成はなんとも古めかしくダサい。

Qvitter プラグインを使うことで、これらはそこそこ解決できる。
Qvitter は GNU social で Twitter のような画面構成を実現するプラグインで、多くの GNU social インスタンスで採用されている。
Quitter.se のように、画面にでかでかと「マイクロブロガー連合は~」と表示されていたら Qvitter 採用サイトだという認識でだいたい問題ないと思う。
Qvitter は初期状態で日本語表示してくれるし、その日本語表現を変更したくなったらテキストエディターで編集してアップロードするだけで済む (Qvitter の locale は gettext ではなく JSON であるため)。

早い話、Qvitter プラグインを使えば、画面構成のダサさも、とりあえずの日本語表示も OK ということ。


先に Softaculous で GNU social をインストールしておいてからの作業になる。
https://github.com/hannesmannerheim/qvitter で zip をダウンロードして展開 (PC に git が入っているなら https://git.gnu.io/h2p/Qvitter を見て git clone)。
zip の場合ディレクトリ名が qvitter-master になっているのを Qvitter にして、plugins/ にディレクトリごとアップロード。
有効化するには GNU social の config.php を編集して↓を追記。

addPlugin('Qvitter');

また Qvitter は Fancy URL を有効にしている必要がある。
Softaculous でインストールした直後の GNU social にアクセスすると https://example.com/index.php/main/all みたいな URL になっているはずだ (サイトタイプが Public の場合。)。
これを https://example.com/main/all にするのが Fancy URL で、Softaculous でインストールした直後には有効になっていない。

というわけで config.php に↓を追記。

$config['site']['fancy'] = true;

Fancy URL は Apache の mod_rewrite で実現するので、htaccess.sample を参考に .htaccess を書く。
参考までに、うちのはこうなってる。

<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteBase /
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteCond %{REQUEST_FILENAME} !-d
	RewriteRule (.*) index.php?p=$1 [L,QSA]
</IfModule>

<FilesMatch "\.(ini)">
	Require all denied
</FilesMatch>

ユーザー登録時に表示される利用規約は plugins/Qvitter/doc/ 下で、これは日本語版がないので英語版が表示されるはずだ (plugins/Qvitter/doc/en/terms.html)。
英語版のファイルを参考に plugins/Qvitter/doc/ja/terms.html を書いてアップロードすれば、ちゃんと日本語版が表示される。文字コードは UTF-8。


これで普段使う部分はだいたい日本語表示になる。
細かいことを気にすると、たとえば登録時やフォロー時に送信されるメイルは英語のままだし、設定画面に入ってしまうとやはり英語だ。
でもそこを気にしてしまうと gettext を入れて .mo を作るクソ面倒な話の始まりだ。
このあたりが妥協ラインではなかろうか。

また、Softaculous でのインストール時点では Fancy URL が有効になっていないために、インストール時に作った管理ユーザーで投稿したものはタイムラインでのリンクがおかしくなる。
これの修正は phpMyAdmin で profile テーブルの id: 1 の profileurl を編集し、「index.php/」を削除すればいい。
よくわからなければ (Fancy URL を有効にした後で) 管理ユーザーとは別に普段使うユーザーを作り、そちらを使う。

国内では Softaculous 採用サービスはあまり見ない印象だが、mixhost が採用しているようだ。


なお、このインストール手法の場合、キュー処理デーモンを使わない運用になるので、大規模なインスタンスには向かない。


電力料金比較表を更新 (2017/04/02)

修正点:

  • ミツウロコでんき@niftyでんきを追加した。
  • 各事業者の料金表をもう一度見直して、こちらの間違いや事業者側の変更などで単価の不一致があったところは直した。
  • エルピオでんきは契約容量によって 120kWh までの単価に差があり、これまではその中で最も高い単価で計算していたが、契約容量ごとの単価で計算するようにした。
  • その事業者がその契約容量でのサービスを提供してないものに関して、従来は同事業者が提供するサービスの中で最も近い契約容量の料金を表示していたが、「提供なし」と表示するようにした。
  • イーレックス・スパーク・マーケティングはブランド名変更で erex になったので直した。
  • ENEOSでんきエルピオでんきerex は料金単価の記載があるページ URL が変更になっていたので、新しいものにリンクを変更した。

エルピオでんきは 30A までの料金も一応掲載しているが、新規申込は 40A 以上に限られている。
プロパンガスでエルピオ利用者である場合のみ「スタンダードライト30A」プランで 30A の新規申込が可能だが、従来の「スタンダードS」プラン 30A よりも基本料金、120kWh までの単価が高い。
表で掲載しているのは「スタンダードS」プランのもの。
新規申込ができないプランについては掲載し続けるかどうか悩ましい。
現エルピオでんき利用者が乗換先を検討するには有用だが、極端に使用量が少ない場合を除けばエルピオが最安値になる現状でその必要もないだろう。

(2017/04/16) やはり申し込めないプランは表示しないようにした。

ENEOS と my は合併で運営会社が同一になったが、料金体系は違う。
今後どうなるかは (自分が ENEOS 利用者であることもあって) 注目したい。

特別高圧・高圧を含む新電力シェアでは上位につけている丸紅新電力も料金計算用のテーブルは作ったが、実際計算してみると全面的に JXTG (ENEOS、my) より高いので比較表掲載は見送り。


(2017/04/07 追記)
今やってる価格.com のキャンペーンだと、@niftyでんきが12ヶ月間、月額1000円引きになるので、契約容量にもよるが 900kWh や 1000kWh 以下の利用量なら1年間の最安値はここになる。
キャンペーン期間、今月末まで。

(2017/05/08 追記)
価格.com のキャンペーン、同じ内容で5月もやっているようだ。


企業メアドへの送信でも特電法違反は成立するよ

日本では特定電子メールの送信の適正化等に関する法律で spam (「迷惑メール」) 送信が禁じられているが、企業メイルアドレスへの送信は規制の対象外だと単純に考えているお花畑 spammer が散見されるので、それは間違いだと示しておきたい。
企業メイルアドレスが宛先であっても特電法違反は成立し得るのだ。

基本的には法第三条第一項第四号が「企業相手なら特定電子メールの送信が違法ではない」と考える根拠になっていると思う。

四  前三号に掲げるもののほか、総務省令・内閣府令で定めるところにより自己の電子メールアドレスを公表している団体又は個人(個人にあっては、営業を営む者に限る。)

メイルアドレスを公開している団体は法第三条第一項第四号に該当し、「送信をしてはならない」相手ではない、というわけだ。
しかしここで終わりではない。「総務省令・内閣府令で定めるところにより」とあることを忘れてはならない。
それは特定電子メールの送信の適正化等に関する法律施行規則第三条で定められている。

(自己の電子メールアドレスの公表の方法)
第三条  法第三条第一項第四号の規定による自己の電子メールアドレスの公表の方法は、自己の電子メールアドレスをインターネットを利用して公衆が閲覧することができる状態に置く方法とする。ただし、自己の電子メールアドレスと併せて特定電子メールの送信をしないように求める旨の文言をインターネットを利用して公衆が閲覧することができる状態に置いたときは、この限りではない。

強調した部分が重要だ。
メイルアドレスを公開していても「特定電子メールお断り」等と付記しているものについては、規制対象になる

日本データ通信協会迷惑メール相談センター 情報提供ページにおいて、メイルアドレスのすぐそばに

このメールアドレスへの情報提供以外の特定電子メールの送信を拒否致します。

と記載されていることからも間違いない。


そういうわけで、株式会社ビーブレイクシステムズ[1]や、ゼロワンインターン[2]の株式会社そると[3][4]は反省するように。

また、株式会社ビーブレイクシステムズが使っている配信スタンドはシナジーマーケティング株式会社[5][6][7]だ。ここは2010年、私の個人メイルアドレスに YUCACEE (ゆかし) spam が届いていたとき、その配信スタンドだった。
シナジーマーケティング株式会社は、あれから6年以上経つ今も変わらず違法行為に荷担しているということになる。シナジーマーケティング株式会社は猛省せよ!


(2017/02/16 追記)

株式会社そるとについてはこんなプレスリリースを見つけた。
ゼロワンインターン spam は前にも酷似したものを見た記憶があったのだが、株式会社アイタンクジャパン[8]のキャリアバイト[9]のものだったと、ようやく記憶がつながった。
株式会社アイタンクジャパンは今月は送ってきていない (のと、たぶん先月送ってきていたと記憶しているが Gmail で spam フォルダーに入ったものを保存していなかった) ので今回「反省するように」のくだりで名前を出していなかった。
株式会社アイタンクジャパン側の主張としては、競業避止特約の不履行、顧客情報の持ち出しということになると思うが、前者はさておき、2社がまったく同じ特電法のお花畑解釈を採る可能性の低さ、2社からほぼ同内容の spam が届く可能性の低さ、2社の関係性を考慮すると、送信先リストの持ち出しは確かに強く疑われてよいと感じる。
株式会社そると側も刑事告訴やら民事訴訟やら始めたようで、個人的には spammer はつぶし合って共倒れしてくれるのが何よりだという認識。いやなら spam 送信という違法行為をやめることだ。

一応本記事では彼らが「不勉強で無知だから違法行為だと知らなかった。だからやってしまった」という逃げ道を残してやっているが、削除要求やら名誉毀損がどうのと抜かすようなら、ド腐れ spammer に見せるこれ以上甘い顔は持ち合わせていない。


(2017/04/16 追記)

株式会社ビーブレイクシステムズはあれからも複数回送信してきている。代表者 (私) の氏名まできっちり書いてきたこともあるので、要するに会社概要のページを見たということだ。そこにははっきりと spam お断りを示す文言を記載している。にも関わらず送信してくるということは、完全に遵法意識が欠落しているものと思われる。このような違法行為を繰り返す、いわば反社会的企業は、利用してはならない。

このほか楽天株式会社からも月4900円出店プランの spam が届いている。「楽天市場 月額4,900円出店プランの最終案内」とあるが、架空請求詐欺のたぐい以外で初回から「最終」だのと言い出すメイルは実に珍しい。
当該プランについてググってみると、実際には決済サービス利用料とやらが別途乗って、どこが4900円だコラって固定費になるようだ。手数料率も Amazon.co.jp マーケットプレイス並、あるいはそれ以上に高い。
ところがそうした説明は、この spam の中には何一つ書かれていない。これは catch じゃないか。


(2017/05/11 追記)

株式会社ビーブレイクシステムズはエゴサーチしているようだ。これで送信を止めないようなら救いようがないな。
楽天株式会社からは申込〆切の日付のみ差し替わったものがまた来ている。楽天は Salesforce を配信スタンドにしている。Salesforce も猛省せよ。


(2017/07/14 追記)

株式会社スクー[10] から spam が届くようになった。まったくコンプライアンスをどう考えてるんだろう。


(2017/09/15 追記)

クロスコ株式会社[11] から spam が届いている。会社の紹介動画作りませんかって、そんなものは何年も前から外人からさんざん spam 来るし、必要だと思えば自分の知ってるとこに頼むものだ。違法行為で飛び込み営業されて誰が買うかってんだ馬鹿め。配信スタンドは株式会社ラクス[12][13][14]。ここも spam 配信スタンドというわけか。
楽天株式会社は、6月に警告を送ってからは送信が行われなくなったようだ。
株式会社ビーブレイクシステムズからはエゴサーチ以後は届いていない。上場発表あたりのエゴサーチで Google のサジェストに「ビーブレイクシステムズ 迷惑メール」なんて出てたわけで、ようやく対応したと見える。
一方、株式会社スクーには8月に警告を送った後も送信が続いている。こちらが明確なオプトアウトをした上でのことだから、完全な違法行為だ。株式会社スクーは違法に spam を送信し続ける反社会的企業であるから、利用すべきではない。


(2017/09/27 追記)

エッジコンサルティング株式会社[15][16] から spam が届いている。自慢の人工知能を spam 送信前に合法性の確認をしてくれるよう修正した方がいいだろうね。SpamCop でさっくり ISP に通報。でも abuse@gmo.jp はちゃんと対応してくれない印象なんだよなあ。


(2017/10/27 追記)

株式会社スクーは8月に警告を送った際のメイルアドレスに spam を送ってきた。本当にどうしようもない犯罪企業だというほかない。


(2017/11/20 追記)

エッジコンサルティング株式会社から spam が届いている。

この度は問合せフォーム自動入力により、
御社の新規開拓営業を圧倒的に高速化する、
営業支援システムのご紹介をさせていただきたく、
ご連絡させていただきました。

企業ウェブサイトによく設置されている問い合わせフォームに対する spam 送信システムだと!
エッジコンサルティング株式会社は完全なド腐れ spammer だ。


(2018/03/01 追記)

ド腐れ spammer エッジコンサルティング株式会社からまた来た。
さくらインターネットと Amazon AWS に通報。

  1. bbreak.co.jp []
  2. 01intern.com []
  3. saltinc.jp []
  4. saltinc.co.jp []
  5. synergy-marketing.co.jp []
  6. synergy360.jp []
  7. crmstyle.com []
  8. i-tank.jp []
  9. careerbaito.com []
  10. schoo.jp []
  11. crossco.co.jp []
  12. rakus.co.jp []
  13. xbit.jp []
  14. hm-f.jp []
  15. edge-consulting.jp []
  16. geaine.jp []

初詣 (平成29年)

今回は2年前同様、終電での移動。

参拝列の最後尾は鳥居をくぐった先で、この時間帯にしてはかなり短い方。
しかしながら列の進みは遅く、結局2年前とほぼ同じ時間になった。


すぐ近くにいた親子連れの子供が非常にやかましく辟易。
とにかく口から先に生まれたような感じの甲高い声でまくしたてるような、おそらく小学生中学年程度の男子。
おそらく親子4人で、父、母、当該クソガキ、その妹という構成。
どうも行列を見て並ぶのがいやになったようで、行列に対する不満を口にし、帰ろうと家族に主張しているのだが、その声がやたらでかく、そして内容が不謹慎に過ぎた。

曰く、

  • こんなに並ぶなら来るんじゃなかった
  • 小さいしょぼい神社でも初詣はできる、わざわざこんな混むところにする必要はない
  • どうせどこの神社でも変わらない
  • お参りしたっていいことなんか何もない
  • 去年もいいことなんか何もなかった
  • 神に会うのに並ぶ必要はない
  • どこの神でも同じ
  • 神は死んだ

これを参拝列の中で1時間も言い続ける有様。

親は一応なだめようとしているのだが、両親揃って息子にナメられているようで全然効果がない。
父親が子供の自尊心に訴えて静かにさせようと試み「子供だな-」と言うと、当該クソガキは「子供だよ!」と即答。
これには吹き出しかけた。

もちろん私を含めてその子供周囲の人々はチラ見、あるいはガン見。
70歳ぐらいの男性がものすごい形相で見ていたが、親すらそれに気づかない。
私は不謹慎コンテンツを好んで楽しむ方だが、さすがに同じネタをループで1時間じゃ飽きる。

子供の妹はそうやかましくもなく、参拝列が進むと無邪気に「進んだー」と言うのだが、それを聞いた当該クソガキは「うるさい!」と当たる。うるさいのはお前だよ。


おみくじは大吉。この神社で大吉以外を引いたのは、確か1回だけだったと思う。

まだ2時前とあって消え物屋台は閉めていない。
じゃがバター (ふかしてる方) と串焼きを食す。串焼きはもう500円では買えない時代か。
始発まで2年ぶりのeワールド府中店で3時間パック。


始発で帰宅したのだが、初日の出もまだ行けることに気づいて出発。
海芝浦は一昨年よりも人出が多く、柵沿いが確保できない。

今日の日の出は6:50だが、水平線からではなく扇島の工場街から上ってくるのを見ることになるので少し遅れる。
7:19の鶴見行きに乗り、そのまま帰宅、元日朝から寝る(笑)。