AWS・Bitnamiの無料枠AMI

今月に入ってからずっとAWSに傾倒している。
特に、BitnamiのAMI（仮想マシンイメージ）
には割とガチで感動した（前回エントリー）。
驚くほど速くサービスを利用できるようになる。

少し興味が湧いたので、BitnamiのAMIのうち
無料枠対象のものについて色々と調べてみた。
なお、無料枠と言っても、あくまでアカウント
登録から12ヶ月間のみなので注意されたし。
（2017年11月調べ）

１．プラットフォーム系

1-1．WordPress(ワードプレス)

AWS Marketplace: WordPress Certified by Bitnami

言わずと知れたブログ・CMSのプラットフォーム。
テーマやプラグインも豊富で、ハッキリ言って
これだけで何でもできそうな気がする。

1-2．MediaWiki(メディアウィキ)

AWS Marketplace: MediaWiki Certified by Bitnami (PV)

OSSのWikiパッケージ。元々はWikipediaを
作成するために開発されたらしいので、
Wikipediaっぽいトピック編集サイト向け。

1-3．Magento(マジェント)

AWS Marketplace: Magento Certified by Bitnami

EC（ネット商取引）サイトのプラットフォーム。
集客機能や接客機能も備えており、
多言語・多通貨にも対応している。

1-4．Discourse(ディスコース)

AWS Marketplace: Discourse powered by Bitnami (PV)

OSSのコミュニティプラットフォーム。
掲示板、グループトーク、チャット等に対応。
フォーラム系サイトを作成したければどうぞ。

２．マネジメント系

2-1．Odoo(オドゥー)

AWS Marketplace: Odoo Certified by Bitnami (PV)

世界的人気を誇るOSSのERPスイート。
ありとあらゆる業務管理や社内統制支援まで
可能にした、ERPの域を超えたパッケージ。

2-2．Liferay(ライフレイ)

AWS Marketplace: Liferay powered by Bitnami (PV)

OSSで世界市場シェア1位の実績がある
ポータルサイトのプラットフォーム。
企業の社内ポータルなどに向いている。

2-3．Mautic(マウティック)

AWS Marketplace: Mautic powered by Bitnami

世界初のOSSマーケティングオートメーション
プラットフォーム。リード（見込み客の）の
獲得や管理を支援してくれるらしい。

2-4．Moodle(ムードル)

AWS Marketplace: Moodle Certified by Bitnami

eラーニング（Webによるオンライン教育）の
プラットフォーム。受験者に対してテストや
教材配布を行ったり、受講者の管理もできる。

３．デベロッパー系

3-1．Redmine(レッドマイン)

AWS Marketplace: Redmine Certified by Bitnami

世界的に有名なプロジェクト管理ツール。
タスク管理や進捗管理などをメンバーで
共有できる。アジャイル開発との相性は抜群。

3-2．Gitlab(ギットラボ)

AWS Marketplace: GitLab CE Certified by Bitnami (PV)

ソースのバージョン管理として有名なGithubの
クローズド環境版（Githubの場合は有償）。
（ちなみに、GitbucketやSubversionのAMIもある）

3-3．Jenkins(ジェンキンス)

AWS Marketplace: Jenkins Certified by Bitnami

物凄くメジャーなCI（継続的インテグレーション）
ツール。ビルド・テスト・デプロイなどの
開発工程の作業の自動化を図ってくれる。

3-4．Let'sChat(レッツチャット)

AWS Marketplace: Let's chat powered by Bitnami

SlackやRocketChatのようなチャットツール。
デスクトップ通知機能もあり、Hubotにも
対応しているのでツールとしては十分実用可。

疲れてきたので、とりあえず今日はこの辺で。
しかし、一つ一つインスタンスを作ってたら
ソッコーで無料枠を使い切りそうなので、
結局は自前で一つのサーバに構築した方が
費用対効果は高いかもしれない。
（Dockerとか使って）

Bitnamiには他にも様々なパッケージAMIが
存在するので、興味がある方はご自身の目で
どうかご確認をおねしゃす。
（無論、使用はすべて自己責任でよろしく）

・AWS Marketplace: Bitnami

・Bitnami Application Catalog

ぼちぼちAWSネタから卒業しようかねぇ。

AWSでWordPress構築(Bitnami)

部署が異動になってからはずっとAWS関連の
仕事に携わることが出来ている。とても嬉しい。

以前はローカルのVirtualBoxに
VagrantでWordPressを構築した際の
備忘録エントリーをアップしたが、
今回は勉強がてらAWSの環境に
WordPressを構築してみた。
なんかWordPressばっかりだな、最近。

０．構築の前提

【アカウント】
AWSサポートプラン：ベーシック(無料枠)

【インスタンス】
AMI：WordPress Certified by Bitnami(無料枠)
インスタンスタイプ：t2.micro(無料枠)
EBS：汎用SSD(GP2) 10GiB(無料枠)

【セキュリティグループ】
SSH(22)…マイIPのみ
HTTP(80)…任意の場所
HTTPS(443)…任意の場所

１．インスタンスの作成

AWSのコンソールから
「サービス」→「EC2」
を選択し、EC2ダッシュボードへ移動する。
上記の前提通りにインスタンスを作成。
（AMI選定時は「AWS MarketPlace」から）

作成時には「キーペア」も一緒に作成され、
SSH接続の際に必要となるので厳重に保管する。

２．グローバルIPアドレスの付与*1

EC2ダッシュボードの下の方に
「Elastic IP」
とやらがあるので選択。
「新しいアドレスの割り当て」
を選んで進んでいくと、
グローバルIPが付与される。

その際、インスタンス作成時に
付与されていたパブリックIPは
削除される。

AWSの世界には３種類のIPアドレスが
存在し、「Elastic IP」が通常は
グローバルIPとして使用される。

IPアドレス	概要
Private IP	インターネットから到達できない。 VPC内での通信に使用できる。
Public IP	インターネットから到達できる。 インスタンス起動のたびに変更される。
Elastic IP	インターネットから到達できる。 インスタンスを起動してもずっと固定。

 
ちなみに今回はやってないけど、AWSの
「Route53」というDNSサービスを使えば
ドメインの設定もできる。

３．WordPressへログイン＆日本語化

この時点で、URLに「http://<Elastic IP>」を
叩けばWordPressの画面にたどり着ける。

早い。早すぎる。慣れてる人なら
数分でWordPress環境を構築できる。
自前でチビチビ入れて5時間かかったのに…

デフォルト設定が英語なので、まずは
管理者権限でログインして日本語化する。
サイドバーの下の方に「Log in」という
リンクを踏むとログイン画面に遷移する。

その際にパスワードが必要になるのだが、
AWSのWordPress導入チュートリアルに
従うと下記の方法により取得する。

1. EC2ダッシュボードで、作成した
   WordPressのインスタンスを選択。
2. 「アクション」→「インスタンスの設定」
   →「システムログの取得」を選択。
3. システムログウィンドウが表示されるので
   その中から見つけてね。
   "#"(ハッシュ)マークで囲まれてるよ。

…確かにあった。

よって、WordPressには下記でログインする。

Username：user
Password：############

無事にログインが出来たら、
「Settings」→「Site Language」
で日本語を選択。これで日本語化完了。

４．phpMyAdminの有効化
　（と、Bitnamiロゴの非表示化）

ご存じの通り、WordPressは
PHPとMySQL(またはMariaDB)で
稼働している。基本的には管理画面から
様々な設定を施すことが出来るので
あまりDBを気にすることはないが、
時にはDBを直接閲覧・編集をしたくなる
シーンも想定される。
そのため、Web画面からphpMyAdminに
アクセスできるように設定する。
（ついでに鬱陶しいロゴも非表示にする）

「１．インスタンスの作成」で作成した
キーペア（秘密鍵）を用いてSSH接続する。
ちなみに「WordPress Certified by Bitnami」は
OSが「Ubuntu 14.04」なので、ユーザーは

ubuntu

である（鍵認証なのでパスワード不要）。
phpMyAdminのアクセス制御ファイルである
「/home/bitnami/apps/phpmyadmin/conf/httpd-app.conf」
について、下記の箇所を修正する。

<IfVersion < 2.3 >
Order allow,deny
# Allow from 127.0.0.1
Allow from <自分のPCのIPアドレス>
Satisfy all
</IfVersion>
<IfVersion >= 2.3>
# Require local
Require all granted
</IfVersion>

Bitnamiのロゴを非表示にするには
下記コマンドを実行する。

sudo /opt/bitnami/apps/wordpress/bnconfig --disable_banner 1

最期に、Apacheを再起動する。

sudo /opt/bitnami/ctlscript.sh restart apache

 これで「http://<Elastic IP>/phpmyadmin」へ
アクセスができるようになる。
DBAユーザー名およびパスワードは

/home/bitnami/apps/wordpress/htdocs/wp-config.php

 に記載されている。

５．WordPressのカスタマイズ

あとは、管理画面からWordPressを
自分好みにカスタマイズするだけである。

正直、WordPress環境をこんなにあっさり
構築できるとは思っていなかった。
最近はレンタルサーバーやVPSでも
WordPressの導入支援機能があるみたいなので、
いずれにしても自分で一からインストールするより
遥かにラクにできるようである。
（当然その分自由度は下がると思うけど）

AWSではRDSというDB管理サービスがあり、
本格的なサイトを構築しようと思うと
このサービスを利用してアプリケーション
サーバとDBサーバを分離した方がいいらしい
けど、今回はお試しなので特に実施予定なし。

AWSでは、いとも簡単にサーバを
作ったり潰したりできるのが素晴らしい。
DR対策もバッチリだし、セキュアだし。
しかしやはり、コスト面は非常に心配。
無料期間が過ぎたら検討の余地アリですな。

流行りモンのLambdaも気が向いたら
触ってみようかね。


～参考にさせていただいたサイト～

*1:グローバルIP(Elastic IP)は$0.01/hで課金されます

ROBOCOPYの堕とし穴

ROBOCOPYの設定値で思いのほか
苦労してしまったので、備忘録メモ。

やりたいこと

簡単のため「Terapad」を例に出すと、

History.txt
Keys.txt
Readme.txt
TeraPad.exe
usr.txt

 という５つのファイルが

C:\test\Terapad

というフォルダに入っており、
この「Terapad」フォルダごと

D:\Terapad

として、ROBOCOPYでコピーしたい。

ハマったこと

通常、ROBOCOPYのコマンドは

ROBOCOPY <src> <dest> [<file> <options>]

という指定をする。
上記の「やりたいこと」を実現しようとすると、

ROBOCOPY "C:\test\Terapad" "D:"

でいいのかな、と安易に考えていた。
それが大いなる勘違いだった。

上記のコマンドを実行すると、
Dドライブ直下に

History.txt
Keys.txt
Readme.txt
TeraPad.exe
usr.txt

がブチ撒けられてしまう。

確かに、よくよくROBOCOPYの仕様を
読んでみると、まぁ確かにそうなんだけど。
でもこんな形のコピーは全く望んでいない。

力技で解決

ウンウンと色々悩んだ末に、力技で解決。
諸事情によりPowershellでゴリゴリ記述。

# コピー元のフルパス
$srcpath = "C:\test\Terapad"
# コピー先のフルパス
$dstroot = "D:\"

# オブジェクト種別によってコピーオプション変更
# $srcpathがフォルダかファイルか判定する
$isDir = Get-Item $srcpath | Where-Object{$_.PSIsContainer}

# フォルダの場合
if($isDir){

  # 「Terapad」のフォルダ名を取得
  $dirname = [System.IO.Path]::GetFileName($srcpath)
 
  # 出力先に「Terapad」フォルダ名を作成
  $dstpath = $dstroot + $dirname
  New-Item $dstpath -itemType Directory > $null
 
  # 遠慮なくROBOCOPYでブチ撒ける
  ROBOCOPY $srcpath $dstpath /E > $null

# ファイルの場合
}else{

  # コピー元のファイル名を取得
  $filename = [System.IO.Path]::GetFileName($srcpath)
 
  # コピー元の親フォルダを取得
  $srcpath = Split-Path $srcpath -parent
 
  # 対象ファイルをブチ撒ける
  ROBOCOPY $srcpath $dstroot $filename > $null
}

 なお、上記ソースは、コピー元のパスが
ファイルの場合もフォルダの場合も対応している。

うーん。
もっとスマートなやり方が
あるのだろうか…

よっこいしょういち

どうでもいいけど、はてなのテーマを変更した。
（スマホだと分からないけど）
以前使用していたテーマでは、「記事一覧」を
表示したときにレイアウト崩れが起こっていて
しゃーなしでの変更。本当にどうでもいい。


最近部署を異動してからというものの、
毎日のように定時に帰ることが出来て
いささか戸惑っている。今の時期が夏なら
明るい空を見上げて涙していたに違いない。

大御所ブロガーであるフミコフミオ先生も
最近再就職に成功し、以前のブラック体質の
企業とのあまりのギャップに当惑されている
ことをブログに綴られている。

記事の中では

戦地から戻ってきた帰還兵がキツイ体験の
フラッシュバックなど後遺症に悩まされ、
普通の生活に戻れないという話を聞くが、
僕もブラックな環境から普通の環境への
順応に苦戦しているのかもしれない。

と言ったことを書かれているが、
僕も気持ちが分かるようになった。
僕の場合は再就職ではなく社内の異動だが、
まったく違う環境でまったく違う人達と
仕事をするという意味ではまったく一緒だ。

手厚いフォロー、ゆとりのあるスケジュール、
先進的な開発環境、技術教育にかける情熱、
何より、僕の周囲を取り囲む、あの
何とも言えないゆる～～～い空気感。
にも関わらず、その中の人たちは
とてつもなく優秀な人たちだった
もはや同じ会社とは思えない。

まだまだ新しい部署に慣れない部分も多いが、
徐々に順応していける見立てはある。
そして、今回の異動について言えば、
この先何があったとしても、
きっと後悔することはないだろう。


…と異動した最初の方は思っていたが、
僕が入るのと同時に、部署の重役たちが
他部署へ次から次へと異動し、気付けば
新部署の体制はスカスカになっていた。
えっ嘘でしょ。

今のところ、この部署の今後については
なんとかなるだろうと楽観視しているが…

はぁ。
本当に大丈夫なんかいね。

（横井庄一さんも戦争神経症だったのでしょうか…）

VagrantでWordPress構築

昨日の勢いで、とりあえずローカル環境に
VagrantでWordPressの構築までやった。
今後のためにメモを残しておく。

０．構築の前提

ホストOS：Windows 10
ホストの仮想基盤：VirtualBox
ゲストOS：CentOS 7.2
ゲストのWebサーバ：NGINX/1.10.2
ゲストのRDBサーバ：MySQL(Ver14.14)

Vagrantのboxファイル：Vagrantbox.esから

vagrant box add <box名> <URL>

でbox listに適当に追加。

１．Vagrantのインスタンス作成

1-1. Vagrantの初期化

Git Bashで適当なフォルダに移動して下記を実行。
（そこがプロジェクトフォルダになる）

vagrant init <box名>

1-2. ゲストOSからホストOS経由でネット接続

プロジェクトフォルダにできたVagrantfileを
下記の通り編集する。

Vagrantfile
：
# Create a private network, which allows host-only access to the machine
# using a specific IP.
config.vm.network "private_network", ip: "192.168.XXX.XXX"　←　コメントアウトを解除する
：

ここまでがホスト（Windows）側の話。
以降はターミナルでssh接続して作業する。

 ２．CentOS7の設定変更

 2-1. rootパスワードを変更

Vagrantで作成したOSのroot初期パスワードが
「vagrant」と安易だったので、適当に変更。
（入力後、新規パスワードの入力が求められる）

#パスワード変更
passwd

2-2. firewalldの設定変更

ダウンロードしたboxは設定が切られていたため、
http通信を許可し、自動起動設定を行う。

#http通信許可
sudo firewall-cmd --add-service=http --permanent
#設定反映
sudo firewall-cmd --reload
#自動起動の設定
systemctl enable firewalld

 2-3. 時刻同期の設定

時刻同期がうまくいってなかったので、
Chronyをインストールして諸々設定。

#Chronyのインストール
sudo yum install -y chrony
#自動起動の設定
sudo systemctl enable chronyd
#タイムゾーンの設定
sudo timedatectl set-timezone Asia/Tokyo
#Chronyの強制反映
chronyc -a makestep

また、「/etc/chrony.conf」には下記を追加。

# Additional Setting
server ntp.nict.jp iburst
stratumweight 0
：
# Allow NTP client access from local network.
allow 192.168.0.0/16
： 

 ３．PHP関連のパッケージ導入

3-1. PHP・PHP-MYSQLのインストール

PHP-MySQLもまとめてインストール。

#インストール
sudo yum install php php-mysql
#バージョン確認
php -v

3-2. PHP-FPMのインストール

PHPのFastCGI実装のひとつ。これがないと
NGINXがPHPを実行できません。
（Apacheの場合は必要ないみたい。多分。）

#インストール
sudo yum -y install php-fpm
#バージョン確認
php -v
#自動起動の設定
sudo chkconfig php-fpm on

４．NGINX導入

4-1. NGINXのインストール

今回はApacheではなくNGINXを使用。
（NGINXの方が高速・軽量らしいので）

#インストール
sudo yum -y install nginx
#バージョン確認
nginx -v
#自動起動の設定
sudo systemctl enable nginx

なお、NGINXはyumに登録されている
バージョンが若干古く、最新の安定版を
取得したい場合は下記の記事を参考にどうぞ。

4-2. PHP-FPMの設定変更、再起動

他所のサイトでも散々書かれているが、
ApacheならWordPressの導入は割と
スンナリ行くが、NGINXの場合はファイル
「/etc/php-fpm.d/www.conf」の変更が必要。

user = apache
user = nginx
：
group = apache
group = nginx

変更後はPHP-FPMを再起動する。

#再起動
sudo systemctl restart php-fpm

５．MySQLの導入

5-1. MySQL-communityのインストール

MySQLをWordPressで利用するには、まずは
MySQL-Communityをインストールする必要が
あるらしいので、とりあえずインストール。

#インストール
sudo yum -y install http://dev.mysql.com/get/mysql-community-release-el6-5.noarch.rpm

5-2. MySQLのインストール

なお、MariaDBもWordPressで使用できるが、
今回は慣れてるMySQLで。

#インストール
sudo yum -y install mysql-server
#バージョン確認
mysql --version
#自動起動の設定
sudo systemctl enable mysqld

６．WordPressの導入

6-1. WordPressのダウンロード

インターネット経由でダウンロードする。
場所はどこでもいいけど、今回は

/var/www

にダウンロードする。

#移動
cd /var/www
#ダウンロード
sudo wget https://ja.wordpress.org/latest-ja.tar.gz
#展開（「wordpress」ディレクトリが出来る）
sudo tar xzf latest-ja.tar.gz
#展開後、圧縮ファイルを削除
sudo rm latest-ja.tar.gz
#「wordpress」からリネームコピー
sudo cp -r wordpress test
#パーミッション変更
chmod 755 /var/www/test

これで、「/var/www/test」をWordPressの
ルートディレクトリとして使用する土台ができた。

6-2. MYSQLにWordPress用のDB作成

WordPressで使用するDBを作成する。
（rootユーザーでログインする）

#MySQLを管理者権限で起動
mysql -u root
mysql> --DB作成
mysql> create database test;
mysql> --ユーザー作成
mysql> grant all on test.* to user@localhost identified by 'password';
mysql> --MySQLを終了
mysql> \q

２・３行目を実行して「Query OK, ～」的な
実行結果が表示されればOK。なお、

　test … DB名
　user … DBAユーザー
　password … DBAユーザーのパスワード

なので、各自変更されたし。

6-3. DBをWordPressへ登録

WordPressの初期ダウンロード状態に
「wp-config-sample.php」があるので、
それをコピーして「wp-config.php」を作成し、
下記の通り変更する。

：
// ** MySQL 設定 - この情報はホスティング先から入手してください。 ** //
/** WordPress のためのデータベース名 */
define('DB_NAME', 'test');
/** MySQL データベースのユーザー名 */
define('DB_USER', 'user');
/** MySQL データベースのパスワード */
define('DB_PASSWORD', 'password');
：
：
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');
define('AUTH_SALT', 'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT', 'put your unique phrase here');
define('NONCE_SALT', 'put your unique phrase here');

test、user、passwordには
「6-2. MYSQLにWordPress用のDB作成」で
設定したものを入れる。
'put your unique phrase here'の箇所には
下記URLで生成された秘密鍵を設定する。

https://api.wordpress.org/secret-key/1.1/salt/

6-4. NGINXの設定ファイルの変更

Apacheの「.htaccess」を使い慣れている人も
多いと思うが、NGINXの場合は「/etc/nginx/nginx.conf」
がそれに該当する設定ファイルである。
下記の通り設定するとうまくいった。

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    root /var/www/test;
    index index.php;
    # Load configuration files for the default server block.
    include /etc/nginx/default.d/*.conf;

    location / {
    }

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    location ~ \.php$ {
    root /var/www/test;
    index index.php;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    }

    error_page 404 /404.html;
    location = /40x.html {
        root /usr/share/nginx/html;
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root /usr/share/nginx/html;
    }
 }

７．ブラウザーからアクセス確認

散々つまづきまくりながら上記の設定を
行い、とりあえずはWordPressの初期画面に
辿り着くことが出来た。
時間にしておよそ5時間ほど。

あとはWordPressの初期設定からである。

ぶっちゃけ、Linuxの操作は慣れてるから
割とサクサクできたけど、WordPressは
あまり触ったことがないので不安である。

とりあえず、プラグインで色々遊んで
徐々にWordPressに慣れていこうと思う。
早くAWSで運用したい…


～参考にさせていただいたサイト～

泡沫の夢に消えないように

最近何かと話題の暗号通貨の案件やらに
何件か顔を出しつつも、友人の
「最近はバブリーな（一過性の）案件ばかり。
　こんな水物のビジネスに手を出すのではなく
　自分のビジネスで稼がなきゃダメだ。」
という発言が引っ掛かり、どこか
モヤモヤしている今日この頃です。

確かにその通りだ。
今年はWeb開発に専念する！と
宣言したと言うのに、私は今まで
一体何をやっていたのでしょうか…

そんなとき、下記のQiitaの記事を読んだ。

「かずきち」氏という、複数のWebサービスを
展開している方のQiitaへの投稿である。

彼の歯に衣着せぬ物言いは見ていて爽快で、
迷える僕に勇気と道標を与えてくれた。


技術者というのは、ともすれば
ビジネス的な視点を度外視し、
純粋な技術知識へ傾倒しがちだが、
「お金を稼ぐ」というただ１点に
フォーカスした場合、高度な技術は
実はさして重要なことではない。

僕は目を覚ました。

何のために技術を学ぶのか。
それは「お金を稼ぐ」ため以外の
何物でもない。金にならない
技術はあくまで趣味の領域で、
マネタイズに至らないものは
ビジネスとしては総じてクソだ。


僕は、アーキテクチャにこだわったり、
流行りものの技術要素を取り入れようと
したり、サービスの公開を第一に考えず
いつまでも言い訳ばかりしていた。

そもそもそれが間違いで、Webサービスなど
「リリースファースト」が当然で、
技術的なブラッシュアップは、ユーザーに
使用されるようになってから考えればいいのだ。

Webサービスなぞ、早い人であれば
たった3日で公開している。
（WordPressでプログラミング一切ナシ！）

素直にすごいと思う。
僕も負けていられない。
「ビジネスに高度な技術は必要ない」
という平城寿さんの言葉がようやく
腹落ちして分かったような気がする。

モチベーションが続いているうちに
とっとと開発をやってしまおうと思い、
久々にAWSのコンソールを開こうとすると、

なんか怒られた。
あまりにも使っていなかったため、
アカウントが利用停止状態に。
くそ、アマゾンめ…
とりあえずサポートに問い合わせ中。

少し出鼻をくじかれてしまったが、
今のモチベーションが続いているうちに
サービスを作り切ってしまおうと思う。


＜特選リンク＞

過去を偲んで喪に服す

今日から晴れて別の部署に異動になった。
本当に嬉しい。サイコー。

かつての部署といえば本当にひどかった。
保守していたシステムはドキュメントも
ソースも煩雑で汚く、レガシーな技術から
抜け出せていないため全く面白味がない。

その上、そこの部門で求められるのは
パートナー企業を使役する鵜飼の能力
あるいは顧客の業務知識ばかり。
「お客様に寄り添うITコンサルティング」
と言えば聞こえはいいが、毎度毎度
無茶な要求ばかりしてくるクライアントに
振り回され、この先衰退していくだけの
ニッチな業務知識しか身に付かず、
時代に取り残された古臭い技術と
心中する覚悟は僕にはなかった。

組織の体制もひどかった。
慢性的な人員不足でメンバーは疲弊し、
教育もサポートも行き届いていない。
管理職は誰も責任を取ろうともせず、
メンバーに無茶な要求を繰り返すだけ。
パートナー企業ばかりがふんぞり返り、
プロパーは人離れで弱体化していく。

本当にもう限界だった。


「会社や仕事なんて理不尽なもんだ」
そう人々は宣うかも知れない。確かにそうだ。
異動先の部署は完全な技術部隊の部署であり、
仕事の内容は全く異なる領域なので
きっと今まで以上に苦悩するだろう。
人員不足はどの部署でも起こっている。

それでも、環境をガラッと変えて仕事がしたい
という思いが揺らぐことはなかった。
（正直、別に転職でもどっちでも良かった）


異動先では早速最新の技術知識が求められ、
勉強やら資格の取得やらが急務となっており、
忙しくも充実した仕事が出来そうで何よりだ。

早く新しい部署に順応し、
目に見える成果をあげたい。

そして、これまでの部署で過ごした
あの呪わしい日々を追悼し、失われた
時間を偲んで供養していきたいと思う。

カメムシコロス

最近、カメムシの数がすごい。

うちは大阪の北摂の古いマンションに
住んでいるわけですが、もう本当に
毎日のようにカメムシと格闘している。

なんか、九州の方でカメムシが大量発生している
というニュースを結構前に耳にしたが、我が家でも
カメムシには随分つらい思いをさせられている。
満を持して「カメムシ注意報」が発令された
九州と比較するのも申し訳ないけど。

古びれた靴を武器に、毎晩毎晩カメムシの
大虐殺を行っているが、殺しても殺しても
後から後からカメムシは湧いてくる。
焼け石に水もいいところである。

カメムシの臭いが苦手な人が結構いるが、
僕は意外とこの臭いが平気なので、気兼ねなく
カメムシを叩き潰しまくっているのだ。
おかげで我がマンションの廊下にはカメムシの
死骸が累々と積み重なり、そして呪詛のごとく
カメムシの臭いが蔓延しているワケである。
隣人さんごめんなさい。犯人は私だ。

しかし、こんな原始的な攻防を繰り広げるのは
流石に疲れる。もっとスマートな戦い方は
ないものか…。そう思ってネットで検索していると
どうやら「カメムシエアゾール」とやらが
効果的な対カメムシ用殺虫剤らしい。

さっそくコーナンに買いにいった。
お値段は1,180円。高ぇ！！
しかし背に腹は代えられない…
まるで初めてエアガンを手にした
中学生のように、僕は嬉々として
我がマンションに向かった。

エレベーターを降りて廊下に出ると、
案の定カメムシが家を出た時より増えている。
僕は購入仕立てのカメムシエアゾールを
開封し、カメムシに向けて噴射しまくった。

意外とシブとく生き残ってたりするが、
思ってたよりポロリと殺せることに驚愕。
何より驚いたのは、駆除作業を開始して
ものの10分でガス切れを起こしたことである。

カメムシエアゾールは、最長射程距離が
4ｍほどあり、一発一発の噴射量がハンパない。
調子に乗って撃ちまくったおかげでソッコー
使い切ってしまったようだ。ここが戦場なら、
敵前で武器を失った僕はきっと死んでいたに
違いない。慢心というのは恐ろしい。

かくして重火器によるカメムシ殲滅を諦めた僕は、
今まで通り原始的な武器で叩き潰している。
うーん、うちのマンションだけなのだろうか。
今までこれほどまでにカメムシの虫害に
見舞われた経験がないのは、今まで運が
良かっただけなのだろうか。誰か教えてほしい。

とりあえず、大家さんに相談してみようと思う。
カメムシコロス。

プロテクト・フロム・ヴァイラス

昨日の今日でなんですが、勢いに乗って
そのまま投稿。明日に響くかも。

久々にブログを更新した後、寝床で
ゴロゴロしながらスマホでネットサーフを
していると、ウィルスに感染してしまった！

ギャー！！！！



なんつって。

こんな糞フィッシングサイト（詐欺サイト）で
今さら驚きはしない。ネタになると思って
スクリーンショットを取りまくってしまった。

しかし何というか手口がエグい。
冷静に考えれば、ブラウザ上でウィルス検出を
一瞬で実行するなんて一体どんな技術力だとか、
いきなり聞いたこともないアンチウィルスソフトの
インストールを制限時間付きで勧めてくるとか、
ツッコミどころに困るような状態ではあるが、
一定数は騙される人もいるんだろな、これ。


フィッシングの再現確認をするために
色んなサイトを徘徊してみたが、下記の
URLからフィッシングサイトにアクセスできた。
（アクセスは自己責任でお願いします）

　http://mobiliela.com

ただし、上記サイトはあくまで
ポップアップ広告を設置しているだけで、
実際にウィルス検知などとふざけたことを
言っているサイトのURLは下記である。

　http://protection-for-phone.com/

製作元を辿っていくと下記サイトに行きつく。

　https://binom.org/

Whois情報でドメインを調べると、どうやら
「Binomlab Lp」とかいうスコットランドの
会社のようだ。ますます胡散臭ぇ…

ちなみに、ウィルス検知の警告をされた後は、
「インストール」を選ぼうが、
「キャンセル」を選ぼうが、
時間切れになるまで放置していようが、
結局は「Powerful Cleaner」とかいう
胡散臭いクリーニングツールのストアに行きつく。
（僕のスマホがAndroidなので）
※絶対にインストールしないでください

おそらく、これは多分アフィリエイトの
一種だろうから、仮にインストールしたとしても
広告主にコミッションが入るだけだろう。
しかし、悪質なアプリの場合、スマホ内の
個人情報を抜き取られる可能性だってあり得る。

まさしく情報化社会の光と影である。
AndroidというOSはLinuxカーネルで、Linuxは
一般的にセキュリティに強いと言われているが、
それはあくまでサーバ用途として使われている
場合の話である。スマホが普及している今、
Androidにも何かしらのセキュリティ対策を
各自で施した方がいいのかも知れない。

僕はめんどくさいからやらないけど。
（標準でウィルス対策ソフト入ってるし）

まぁ同じAndroidユーザーは注意されたし。


しかし…

いったい何種類の詐欺サイト作れば
気が済むんですか。あなた方は。

勝って兜の緒を締めたい

今宵は中秋の名月らしい。

しかし、相も変わらずの更新頻度である。
最終更新が１か月前とは、中々思うように
書くことが出来ていない。
特筆して書くことがなかったのかと言えば
決してそうではない。この１か月の間、
それなりに色々なことがあった。

◆暗号通貨バブルの恩恵が会社バレした

まぁこれは別に大した話ではないが、
Bitcoinを始めとする暗号通貨（仮想通貨）の
目覚ましい爆騰により、それなりの額の含み益を
出していることが会社バレしてしまった。
今では仮想通貨長者扱い。なんでやねん。

つい嬉しくなってうっかり飲み会の席で
口を滑らしてしまったわけだが、別に
問題になっているわけでもないし別にいいか…
不動産もぼちぼちバレ始めてるしなぁ…

◆ボランティア企画への参加

うちの会社のCSR活動の一環でもある
ボランティア活動に初参加。
入社当時から参加したいという思いはあったが、
仕事が忙しくてつい尻込みしてしまい
参加できずにいたが、今年は満を持しての参加。

障害者とそのご家族と話をする機会が
ふんだんにあり、色々と考えさせられた。
五体満足なだけでも恵まれたことだと痛感。
来年も参加するかどうかは悩み中だが、はて。

◆来月から別の部署へ異動！

異動すること自体は決まっていたが、
まさかこんなに早く異動できるとは
思っていなかった。ラッキー。慰留も特に
されなかったし、きっと僕は今の部署に
必要とされていない人間なのでしょう…
（というか、人事の決定は今さら覆せない）
１秒でも早く異動したいので、結果オーライ。

後任者への引継ぎ作業を進めていたけれど、
残念ながらメンタルを病んで休職してしまった。
別の後任者を立てられはしたが、その人では今後
プロジェクトは確実に立ち行かなくなるだろう。
ホントに、いったいどうするつもりなんだ…
まぁいいや、もう知ーらね。

とりあえず、なんやかんやと上半期が過ぎた。
途中、なんやかんやでアンニュイな気分になり
社外活動が一切できなかったりしたが、異動に
成功したり、副収入を増やしたりできたので、
戦果としては上出来だったのではなかろうか。

しかし下半期以降、環境がガラッと変わるので
いっそうの自身の実力が試されるというものだ。
慢心せず、気を引き締めて挑むとしましょうか。

（兜の緒を締めてるイメージ）

真田幸村かっけー。