Jenkins環境構築

まずインストールする
 wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
 rpm –import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
 yum install java-1.7.0-openjdk
 yum install jenkins
 systemctl enable jenkins
 systemctl start jenkins

続いて初期設定
 ブラウザでアクセス。
  http://localhost:8080/
 初期パスワードを取得し、表示下画面に入力
  >cat /var/lib/jenkins/secrets/initialAdminPassword

続いてプロジェクトの作成
・プロジェクト名を入れる
・「古いビルドの破棄」にチェックを入れる
・Log Rotation を選んで保存日数を入力。30日くらい?
・ソースコード管理でGitを選択
・Repository URL にはリポジトリのURLを。
・ブランチのところは */develop
・ビルドトリガはとりあえず「定期的に実行」で以下のように、クーロンのように。
       H 1 * * *

プラグインを入れる


デザイン(認知的負荷)

・覚えていないとできないようなデザインは良くない。
・アイコンを表示するなら、テキストも添える。
   直感的なアイコン、、意外と人によって認知が異なって不便なことが多いことが研究でわかっているとのこと。
・分かりづらい表現は避ける
・アクション(タスク)が多いものは避ける

運用保守フローさんぷる

トラブル発生した時って、その対応の流れってシンプルなはずなんだけど、複雑化する傾向がある。
それは、トラブルに向き合った人の立場によって、やらなきゃいけ無いことが変わってくるんだけど、
その違いにより、優先順位が変わっちゃうんですね。
どの立場の人がいつ何をしなきゃいけ無いのか、特に組織になった時、うまーく立ち振る舞いできると
いいなぁと思います。
ここでは、大まかな流れを書きます。実際のアクションは扱うシステムの種類であったり、組織の性質
によって変わるとおもいますので、それぞれの状況に合わせて考えてね。

0)全体を通してやらないといけないこと
・時系列の記録
・二次災害の防止
・利害関係者との合意に基づく行動
・利害関係者へのタイムリーな報告相談

1)障害対応
・直接の障害原因の把握
・サービスの暫定復旧

2)恒久対応
・障害発生の根本原因の特定
・根本原因の排除(対策の実施と、その後の除去監視)

3)改善対応
・類似障害発生のアセスメント
・類似障害発生のリスクコントロール

特に、1)障害対応、は以下のように進めます。
1:障害の検知
  黙っていると怒られます(笑)
  まずは、「素直に」「判断を入れず」に客観的な情報を伝えます。
   ・検知時刻/検知者/現象/検知方法
   ・利害関係者への障害検知通達
   ・影響範囲

2:一次復旧手順の作成
  次に、今の状況をまず打開して、最低限で良いのでサービスを再開するための
  手立てを考えます。ただし無理は禁物です。ポイントは、二次災害をおこさない
  ことと、再度すぐにサービスがダウンしないことです。
   ・直接原因の特定
   ・直接原因の排除手順作成
   ・直接原因の排除による既存サービスへの影響確認

3:一次復旧手順の実施
  ここでの作業が結果的に恒久策になることもありますが、得てして根本原因は
  他にあるものです。過信せず、二次災害を起こさないように、冷静に安全に
  まず目の前の停止状態より一歩前に進めましょう。
   ・一次復旧手順実施を利害関係者と合意
   ・一次復旧手順を実施
   ・一次復旧を確認(障害箇所と既存サービス全体)
   ・流動監視

4:一次復旧報告
  報告書に以下をまとめましょう。再発防止策を記載すると、障害を前向きにもっていく
  ことができることが多いのでぜひ検討したいところです。
   ・一連のフローを報告
   ・現状を報告
   ・残課題を報告
   ・目先の再発防止策を報告

以上

ClamAVのリソース占有問題

Virusチェックは、なんだかんだCPUリソースを使う。
これはパソコンに限らず、サーバも一緒。

無料なんで、それなりのインストール数取っているであろうCalmAV
これもやっぱりCPUをよく食らう。

お行儀よくしたいなーって思っていたら、デーモン化することでCGroups
で制御できるぞ、との記事を発見!

ClamAVをCGroupで管理してCPUを節約する

EC-CUBE3でREST-APIを使う

以下で進めてたんですけど、
・EC-CUBE3用のWebAPIまだベータ版で本気サービスにはまだ使え無い。
・MySQLの制約に引っかかって、有効化できない
という問題を抱えています。まだまだかな。

ーーーーー
まず、EC-CUBE3を入れる。

wget http://downloads.ec-cube.net/src/eccube-3.0.12-p1.zip
unzip eccube-3.0.12-p1.zip

Apacheの設定をする(詳細は省略)
※なるべくhttpsで接続できるようにね。

DBをcreateしておく

アクセスする
https://DocumentRoot/html/

あとは、画面に促されるままに。

次に、API接続して商品情報を取ってみる。
基本はここ。
http://ec-cube.github.io/api.html
http://ec-cube.github.io/web-api-doc.html

CakePHP3でログ出力する

Log出力の設定は、以下にある。(ログ出力レベルの設定)
config/app.php

実際の出力は以下の様にする。

use Cake\Log\Log;
...
Log::warning('this gets written only to error.log', ['scope' => ['error']]);

warning() を使っているが、,この他に emergency(), alert(), critical(), error(), notice(), debug(), info() などがある

Webサービス開発

<デザイン>
・デバイスを決める
   PC
   スマホ
   Tablet
・表示環境を決める
  Windows/ IE/Edge/Chrome/Firefox
  Mac/ Safari/Chrome/Firefox
Android 標準/Chrome
iOS/ 標準/Chrome
・画面幅の最大、最小を決める。
・レスポンシブのルールを決める。
     ブレイクポイントを決める

<開発規約的なこと>
・HTML
  div,spanの使い分けを明確にすること。
  margin,paddingの使い分けを明確にすること。

・JavaScript
  ・confirm
    返り値が、true/false
   chromeでは「非表示」が可能。
   非表示にした場合の返り値は「false」
   非表示=falseが仕様上不適切な場合は、confirmは使用禁止
   非表示=trueの場合、そもそもconfirmはいらないでしょう。

・CSS
 ・記載の順番
   @media指定なし。
   @media指定あり(かつサイズの大きい順に記載する)
 ・直接のStyle指定はしないこと。
 ・基本的には、class指定で共通化を意識すること。
 ・id指定をするときは、JavaScriptでの動作制御が必要な時を基本とする。
    (複雑化するので、id指定でのstyle指定はあまりしないこと)
・マージン調整にて、パーセント指定とピクセル指定を混在しないこと。

<WEBを作るサービス>
BiND9
http://www.digitalstage.jp/bind/

Wix
http://ja.wix.com/