特に難しいことはなく以下の通りです。
pm2 start hoge.sh

.shに引数をつける場合は
pm2 start hoge.sh -- run # ここでは run が引数

今回はこれだけです。
それでは。


はじめに

これまで社内でRuby Sassを使っていましたが、さすがにそろそろ乗り換えないといけないと思い、node-sassに変更しました。
そこで発生した問題が、コンパイル後のCSS差分でした。
会社ではエンジニアはWindows、デザイナはMacを使っているのですが、node-sassにしてからコンパイル後のCSSがWindowsとMacで毎回diffが出てしまいました。
今回はこの問題を解消した話です。

差分の内容

吐き出されたCSSの主要部分には差分は無く、表示上の問題はありませんでした。
差分が出たのはCSSのコメント部分です。
SCSSのコメントは問題ありません。
具体的には、CSSの複数行コメントがWindowsでは複数行で吐き出され、Macでは1行で吐き出されるという差分です。
コンパイルのオプションは以下で統一していました。
--source-map true --output-style compact
実際に起きていた差分は以下のようなものです。
Mac
/* ここはコメントです */

Windows
/*
  ここはコメントです
*/

原因と対処方法

原因はWindowsとMacの改行コードの違いとGit for Windowsのautocrlfです。
対処方法としては、まずSCSSのファイルの改行コードをすべてLFに変更します。
自分はPhpStormを使っているので、以下手順で実行しました。


Project から css ディレクトリを選択して Ctrl + Shift + A をして lf を実行
続いて、Gitのautocrlf を無効にします。
ターミナルから git config --global core.autocrlf false
コンパイルのオプションに以下を追加。
--linefeed lf
最後に、PhpStormのデフォルト改行コードを変更します。
Settings → Editor → Code Style → Line separator: Unix and OS X (\n) にする
これで吐き出されるCSSがMacと同じになります。
Mac
/* ここはコメントです */

Windows
/* ここはコメントです */

まとめ

なんとなくGitやSassを導入してそのまま運用してきてしまったがために今回かなり苦労する羽目になりました。
そのような現場も多いと思います。
今後は使えるなと思った段階で設定周りに問題が出ないか振り返るようにしていきたいと感じた出来事でした。

18. 1月 2019 · Write a comment · Categories: GROWI · Tags: ,



はじめに

社内で技術共有をする時にもともとはCrowiを使っていました。
Crowiはとてもよくできた社内Wikiで、1年ほど前にお試しで導入していました。
最初お試しで導入のつもりが気が付いたら無くてはならないものになることってよくあると思うのですが、
自分のチームにとってCrowiがまさにその状態でした。
それがまさかあんなことになるとは。。。


悲劇は突然起きた

今年の正月休み明けに、社内で使っているサーバーを再起動しました。
まあ、毎年恒例です。
その際に、Crowiが入っているサーバーのHDDがお亡くなりになりました。
インフラ担当のエンジニアから復旧はできないと言われました。
Crowiは気軽な感じでチームで使い続けていたためバックアップを全くとっていませんでした。
この1年貯めてきたナレッジがすべて泡となって消えた瞬間でした。
チームのメンバーには土下座しても許してもらえないレベルの出来事をはじめて経験しました。
笑って許してくれたチームメンバーには本当に感謝しています。


Crowi → GROWI への乗り換え

Crowiに貯めてきたナレッジはすべて消えてしまいましたが、Crowi無しでこの後業務をしていくのは非常に効率が悪いということでゼロから立てることにしました。
その際、Crowiをやめて以前から興味のあったGROWIに移行することにしました。
この時はちょっと権限を使って有無を言わさずGROWIにさせてもらいました。


設定方法


設定方法は基本的に公式に書いてある通りに進めていけば問題ないです。
今回は社内サーバーなのでHerokuではなくオンプレです。
nodeとnpmは入っている前提で。
nodeのバージョンが8.xでなければいけないとのことなのでnを使ってバージョンをv8.11.4にしました。
yarnが必要ですが、インストールされていなかったのでインストールしました。

npm install -g yarn

MongoDBは指定の3.xがインストールされていたのでそのまま使いました。
あとはgithubからcloneしてきてyarnでビルドします。

cd /opt
git clone https://github.com/weseek/growi.git
cd growi
yarn

yarnが成功したら起動用のスクリプトを作ります。

vi growi.sh

export PORT=2019 # 起動したいポートを指定。デフォルトは3000ですが空いてなったので。
export PASSWORD_SEED=crowigrowi # パスワードのハッシュ生成に使います。外部公開しないので適当につけてしまいました。
export MONGO_URI=mongodb://localhost:27017/growi # mongoDBへのURIです。同サーバー内にしたのでlocalhostでポートはmongoDBデフォルトの27017です。
export ELASTICSEARCH_URI=http://localhost:9200 # 検索にElasticSearchを使う場合は指定
export FILE_UPLOAD=local # ファイルのアップロード先を指定。今回はローカルで。
npm run server:prod # GROWI起動コマンド

このまま起動するとターミナルを閉じたときに停止してしまうので、pm2を使って永続化させます。

npm install -g pm2

起動します。

pm2 start growi.sh

まとめ

今回は改めてバックアップの重要性を思い知らされました。
当たり前の話ですが、意外と皆さんにも心当たりがあるのではないでしょうか。
取り返しのつかないことになる前にやっときましょう…


03. 12月 2018 · Write a comment · Categories: GitLab · Tags:



はじめに

最近チーム内でGitLabを使い始めました。
レガシーな環境から抜け出したい一心ですがなかなかうまくいかんですね。
今回初めてGitLabのアップデートを行ったので備忘録として書いておきます。


環境

  • CentOS6
  • GitLab EE

アップデート方法

アップデート方法と書きましたが、基本的にはyumでinstallするだけです。

sudo yum install -y gitlab-ee

しばらく待ってGitLabのアスキーアートが表示されたら完了です。
ブラウザでアクセスすると502が表示されることがありますが、1分ほど待ってから再度アクセスすると更新されたGitLabが表示されます。
他の環境の方はこちらから。
https://about.gitlab.com/update/




はじめに

最近オフィスで仕事をしていると、たまに「異常にネットが遅い。。。」と感じるときがあります。
これは計測のしがいがありますね!!
Don’t guess! Measure!
というわけで、ネット回線のスピードテストを自動実行して視覚化してみました。


 

やったこと

  • speedtest-cliをcron実行
  • 結果を記録
  • 記録したデータをグラフにする

計測方法

本当はGoogleスピードテストをヘッドレスブラウザから叩くようにしたかったんですが、環境作るのに手間がかかりそうだったのでやめました。
今回利用したのは、speedtest-cliというCLIで実行できるツールです。
こちらはPython製ですが、Pythonのコードは一切書いていません。
ただ、Pythonの実行環境というかpipというパッケージ管理ツールが必要となります。
以前、Pythonの環境は整えていたので今回はスムーズに導入できました。
実行環境はCentOS6です。


speedtest-cliをインストール

pip install speedtest-cli

インストールが完了したらターミナルから

speedtest

と叩くだけで回線速度の計測ができます。
しかし、これだとpingから最適な計測サーバーを選択するらしく毎回違うサーバーにつながってしまいます。
同じサーバーにつなげて時間以外の条件を変えずに計測を行いたかったので、以下のオプションのようにして実行します。

speedtest --simple --server 14623

--simpleオプションは実行結果をシンプルに表示します。
--server 14623で東京サーバーを指定しています。
サーバーは世界中にあるのですが、日本のサーバーを利用したい場合は以下のようにすると一覧を表示できます。

speedtest --list|grep -i japan
14623) IPA CyberLab (Bunkyo, Japan) [2.57 km]
 6492) denpa893 (Sumida, Japan) [6.13 km]
15047) OPEN Project (via 20G SINET) (Tokyo, Japan) [6.15 km]
18838) BGP Network (Tokyo, Japan) [6.15 km]
20976) GLBB Japan (Tokyo, Japan) [6.15 km]
19256) Love4Taylor (Tokyo, Japan) [6.15 km]
 6508) at2wn (Yokohama, Japan) [28.67 km]
 8407) Allied Telesis Capital Corporation (Sagamihara, Japan) [36.44 km]
 6087) Allied Telesis Capital Corporation (Fussa-shi, Japan) [38.13 km]
 7139) SoftEther Corporation (Tsukuba, Japan) [48.03 km]
19038) poteitooo (Nagoya, Japan) [263.76 km]
 6766) JAIST(ino-lab) (Nomi, Japan) [300.32 km]
 6368) gatolabo (Maibara, Japan) [316.59 km]
 6476) rxy (individual) (Osaka, Japan) [401.52 km]
 6405) Allied Telesis Capital Corporation (Misawa, Japan) [573.40 km]
19915) CloudRemix(IDCF) (Kitakyushu, Japan) [834.67 km]
18709) extride inc (Hitoyoshi, Japan) [914.25 km]
  811) GLBB Japan KK (Chatan, Japan) [1543.58 km]
 6581) haza (Haebaru, Japan) [1556.20 km]
21118) GLBB Japan (Naha, Japan) [1557.98 km]

シンプル表示で実行すると以下のような結果が表示されます。

speedtest --simple --server 14623
Ping: 32.296 ms
Download: 79.92 Mbit/s
Upload: 92.78 Mbit/s

計測結果を記録してグラフにする



ここまでで、ネット回線の速度は計測ができました。
続いてこちらを記録してグラフにします。
ここから急にPHPになりますがご容赦ください。

<?php

$now = date('Y-m-d H:i:s');
$result = array();
exec("speedtest --simple --server 14623", $result);

if (!$result) {
    exit;
}

// あとはcsvファイルとして記録する
$csv = implode(",", $result);
$fileName = "speedtest.csv";
$fp = fopen($fileName, "a");
fwrite($fp, $csv . ',' . $now);
fwrite($fp, "\n");
fclose($fp);

シェルでやるのが面倒くさかったので、PHPからexecで叩いてcsvファイルに記録することにしました。
こちらのPHPをcronに登録して15分毎に計測していきます。
1日あればそこそこデータとれます。
データが貯まったらcsvファイルをスプレッドシートに投げてグラフを表示します。






※実データだとまずい気がしたので、グラフは一部加工しています。


まとめ

実際に計測してみると、やはり夕方から夜にかけてどんどん速度が落ちていることがわかりました。
感覚で遅くなったと言ってもなかなか改善に動いてくれる人は少ないですが、数字とかグラフで視覚化するとあっさり動いてくれたりします。
speedtest-cliはWindowsでもPythonをインストールすれば動きますので、ネット回線の速度を計測したい人は試してみると良いと思います。
それでは、快適なネットライフを。


28. 10月 2018 · Write a comment · Categories: その他 · Tags:



はじめに

中部地方でWebエンジニアをしています。今回自社運営しているサイトを常時SSL対応しました。
先日、日本時間2018年10月17日にChrome70がリリースされ、HTTPSでないページへの警告がさらにまた1つ進みました。
まだ現状ではHTTPのページも閲覧はできますが、この先常時SSL対応していないサイトはどんどん閉め出されていくことが予想されます。
また、ServiceWorkerなどの技術を導入する際も常時SSL対応がされていないと導入できなかったり(しにくかったり)と常時SSLでないことのデメリットは増えていく一方です。
今回、自社サイトの常時SSL対応をするにあたって行った内容を記述します。
サイト規模はざっくりとしかお伝えできませんが、デイリーPVが200万超えるくらいです。


 

やったこと

  • Mixed Contentの収集
  • ひたすら書き換え
  • 強制SSLリダイレクト

Mixed Contentの収集

常時SSL対応をするにあたってここが一番重要かと思うのですが、実際のユーザーの手元で発生しているMixed Contentを把握する必要があります。
そこで行ったのがContent-Security-Policyの設定です。
どういうことかと言いますと、ヘッダー情報にMixed Contentの発生を通知するような情報を追加します。
これにより、ユーザーの手元で発生したMixed Contentの内容が把握できるようになります。
具体的には.htaccessに以下のような記述を追加しました。


Header set Content-Security-Policy-Report-Only: "block-all-mixed-content; report-uri https://example.com/mixedcontentreport.php"

こうすると、Mixed Contentが発生した際にその内容が https://example.com/mixedcontentreport.php に json で POST されます。
https://example.com/mixedcontentreport.php の部分はご自身の環境にあわせて書き換えてください。
POSTされてくる json は以下のような内容となっています。


{
  "csp-report": {
    "document-uri": "https://example.com/hogehoge/",
    "referrer": "https://example.com/hogehoge/fugafuga/",
    "violated-directive": "block-all-mixed-content",
    "effective-directive": "block-all-mixed-content",
    "original-policy": "block-all-mixed-content; report-uri https://example.com/mixedcontentreport.php",
    "disposition": "report",
    "blocked-uri": "http://example.com/foo.png",
    "line-number": 1,
    "source-file": "https://example.com/hogehoge/",
    "status-code": 0,
    "script-sample": ""
  }
}

上記の例だと https://example.com/hogehoge/ にアクセスした際に http://example.com/foo.png で Mixed Content が発生しています。
この情報を DB に記録してひたすらMixed Contentを潰していかなければなりません。
不毛とも思える対応ですが、他に方法はありません。(あったら教えてください。。。)



ひたすら書き換え

Mixed Content収集の準備が整ったら、続いて HTML、CSS、JavaScript の書き換えを行います。
こちらに関しては要するにリクエストが発生する箇所をすべてHTTPSで読み込むように書き換えます。
使用しているフレームワークによってはある程度システム的に置き換えも可能だと思いますので、こちらに関してはサイトによって対応が変わってきます。


強制SSLリダイレクト

こここまでの対応で常時SSL化の対応準備が整いました。
最後にユーザーからのアクセスを強制的にHTTPSにリダイレクトさせます。
こちらに関しては .htaccess で対応、PHP で対応、ロードバランサで対応などいろいろ考えられますが、まずはアクセスの1%を強制SSLリダイレクトすることをオススメします。
いきなり全アクセスをSSLにしてしまうと影響範囲が大きすぎるため夜中の対応を強いられることになるかもしれません。。。
別に私がそうだったわけではありませんが。。。


まとめ

常時SSL化の対応をしないという選択肢は正直ありえませんので、もしまだ対応をしていないようであれば一刻も早く対応をしたほうが良いかと思います。
やること自体は至ってシンプルですが、ただ面倒くさいのは事実です。
まずは状況把握としてMixedContentの収集をしてみてはいかがでしょうか?


15. 10月 2018 · Write a comment · Categories: PHP · Tags: ,



はじめに

私の職場があるビルはいわゆるランドマークタワーで、地元ではこの中で働いているというだけで何故か信頼を得られるのですが、実際は空調が一元管理されておりあまり融通が効かず快適な職場とは言えません。
そこで導入されたのが NETATMO ウェザーステーションです。
こちらを使って気温や CO2 濃度の計測をして、社内で決められた値を超えたら管理部門に電話をするようになりました。
しかし、この情報は NETATMO 専用の Web サイトにアクセスして確認しなければならず、忙しい業務中に確認するというのは現実的ではありませんでした。
そこで今回、NETATMO API から気温・CO2 を取得し社員が頻繁に見ている社内管理ツール上に表示するようにしてみました。


 

やりたいこと

  • NETATMO API から情報を取得

NETATMO CONNECT に登録

NETATMO API を利用するするにはアプリケーションの登録が必要となります。NETATMO CONNECT に登録をします。
※NETATMO ウェザーステーションをすでに利用している前提の話です。


netatmo connect



必須項目は2018年10月現在、以下3つです。それぞれ入力します。

  • Name
    • 作成するアプリ名です
    • 深く考える必要はありません。私は「officeAtmo」としました。
  • Description
    • アプリの説明です
    • これも深く考える必要はありません。私は「管理ツール用」としました。
  • Data Protection Officer name
    • データ保護責任者の名前
    • 会社組織の場合、該当者がいるはずですのでその方の名前を入れます
    • 事前に確認了承を得てください

登録が完了すると TECHNICAL PARAMETERS の登録となりますが、こちらは特になにも入力しなくて大丈夫です。
ただし、表示されている Client id と Client secret は API で使います。


technical param




これで事前準備は完了です。ここからは実際に API を叩いてみます。


実装

私は PHPer なので PHP での実装となります。
とりあえずコード貼ります。


<?php
// NETATMO CONNECT に登録した内容で認証 API を curl で叩く
$netatmoAuth = array(
    'client_id'     => CLIENT_ID,
    'client_secret' => CLIENT_SECRET,
    'grant_type'    => 'password',
    'username'      => MAIL_ADDRESS,
    'password'      => PASSWORD,
);
$url = 'https://api.netatmo.com/oauth2/token';
// 自作 curl ライブラリ
$requestObj = new CurlHttpRequest($url, $netatmoAuth);
$timeOutSecond = 30;
// POST で
$response = $requestObj->post($timeOutSecond);

// 例外処理は適宜入れてください

// 認証情報が json で返ってくるので decode する
$response = json_decode($response['body'], true);

// 取得した認証情報のアクセストークンを使って現在のウェザーステーション情報を取得
$url = "https://api.netatmo.com/api/getstationsdata?access_token={$response['access_token']}";
$requestObj = new CurlHttpRequest($url);
$timeOutSecond = 30;
// 今度は GET で
$response = $requestObj->get($timeOutSecond);
$response = json_decode($response['body'], true);
// 気温
$netatmo['temperature'] = $response['body']['devices'][0]['dashboard_data']['Temperature'];
// CO2 濃度
$netatmo['co2'] = $response['body']['devices'][0]['dashboard_data']['CO2'];
// 湿度
$netatmo['humidity'] = $response['body']['devices'][0]['dashboard_data']['Humidity'];


Netatmo API へのアクセスは curl で行っていますが上記の例では自作の curl ラッパークラスを使っていますので、適宜ご自身の環境で書き換えてください。
まずは認証を通過する必要があるので、認証 API を叩いています。今回は閉じた環境でサクッと利用するために簡易的な方法をとっています。
grant_type に password を指定して、NETATMO CONNECT に登録した内容と取得した Client id と Client secret で POST リクエストを送ります。
認証結果が json で返却され、中にアクセストークンが含まれています。
続いてアクセストークンを使って現在のウェザーステーション情報を取得します。
こちらも json で結果が返ってくるので、その中から必要な部分を抜き出します。今回は気温・CO2濃度・湿度を社内の管理画面に表示させてみました。


まとめ

実際の管理画面はお見せできませんが、これで気になったときにすぐオフィスの快適度が数値として分かるようになりました。
まあ、そこから管理部門に電話しなきゃいけないんですけどね。。。ハードル高すぎ。。。
では快適な職場ライフを。。。