APTについて

APTとは

APT (Advanced Packaging Tool) は、Debian用に開発されたパッケージ管理システムである。OSに何らかのソフトウェアを追加インストールする場合には、ソフトウェアに関係するファイル一式をまとめた「パッケージ」が利用されるが、APTでは、Debian用に開発されたdebパッケージ形式を対象としている。
APTはコンパイル済みのソフトウェアを管理する機能に加え、ソースコードからソフトウェアをコンパイルする際の依存関係を解決する機能も備えている。
apt-get(*1)やapt-cache(*2)等の複数のコマンドから成る。配布パッケージの自動入手先として、インターネット、LAN、CD-ROM等をapt-line(*3)として複数指定することができる。

*1 apt-get

　パッケージのインストール、削除。
APTの 最も基本的なインタフェースの一つ。 コマンドラインベースでコマンドを発行するためのもの。 apt-get install パッケージ名というように指定すると、 指定した名前のパッケージをインストールしてくれる。

*2 apt-chache 

　パッケージ名や説明に関しての検索機能、情報を提供。

*3 apt-line

　apt-getの設定ファイルである/etc/apt/sources.listに記入する設定行。（パッケージの入手先）

代表的なコマンドと使い方

以下、から引用させていただきました。

APT - Wikipedia

追加・ダウンロード

• 新しいソフトウェアのインストール（root権限が必要）
  apt-get install パッケージ名 [ Enter ]
• ソースパッケージのダウンロード
  apt-get source パッケージ名 [ Enter ]
• ソースパッケージをコンパイルする為に必要なパッケージのインストール（root権限が必要）
  apt-get build-dep パッケージ名 [ Enter ]

更新

• リポジトリの更新（root権限が必要）
  [ソースを追加したとき、ひさしぶりに使うときは必ず apt-get を更新します。これをしないと古いものを参照してしまうことになる。]
  apt-get update [ Enter ]
• インストール済みのソフトウェアの更新（root権限が必要）
  apt-get upgrade [ Enter ]
• ディストリビューションのアップグレード（root権限が必要）
  apt-get dist-upgrade [ Enter ]

 またこれらapt-getコマンドを使用すると、システムに必要なパッケージが存在しない場合、その不足している依存性パッケージを自動的に判別し、そのパッケージも同時にインストールしてくれる。dist-upgradeを指定した場合、更新可能なすべてのパッケージに対して依存関係を解析し、重要なアップデートを更新するが、依存関係の問題から重要でないパッケージは削除される場合もある。

検索・情報表示

• パッケージの検索
  apt-cache search 検索キーワード [ Enter ]
• 特定パッケージの情報表示
  apt-cache show パッケージ名 [ Enter ]

削除

• 特定パッケージの削除
  apt-get remove パッケージ名 [ Enter ]
• 特定パッケージの設定ファイルを含めた削除
  apt-get purge パッケージ名 [ Enter ]
• 不要なパッケージの自動削除(依存されていないライブラリ等)（root権限が必要）
  apt-get autoremove [ Enter ]

使用の流れ(例：gimpのインストール)

• リポジトリの更新
  # apt-get update
• 探す
  # apt-cach search vim
• 詳細を見る
  # apt-cache show vim
  　検索結果が多すぎる場合、 正規表現 を使う。
  　完全一致: $ apt-cache search ^vim$
  　前方一致: $ apt-cache search ^vim
• インストールする
  # apt-get install vim
• インストールしたアプリケーションの一覧を見る
  # dpkg -l
• インストールしたアプリケーションの設定ファイル等の場所を調べる
  # dpkg -L gimp

参考サイト

第2章 Debian パッケージ管理

APT - Wikipedia

apt-getの使い方 - Liquidfuncの日記

さくらVPSにDebian8をインストールする

目的

さくらＶＰＳにサーバ環境を構築する。
ＯＳはDebian８。

• さくらＶＰＳにDebian８インストール
• sudoのインストールと設定
• sshのインストールと設定

さくらＶＰＳにDebian８インストール

さくらVPSのサーバ設定画面→OSインストール→カスタムOSインストール→インストールOSに「Debian 8 amd64」を選択→「設定内容を確認する」押下→「インストールを実行する」押下。

「Debian　GNU/Linux installer boot menu」表示され、開始。
各設定項目の詳細は、参考サイトに記載した「Debian 管理者ハンドブック

4.2. インストール作業の各段階」に詳しく記載されています。

インストールの流れ

1. Configure the keyboard

　・Japanese

2. Configure the network

• IP address　　(さくらネットワーク情報のIPv4のアドレスを入力)
• Netmask　　　( 同上、ネットマスクの情報を入力)
• Gateway 　　 (同上、ゲートウェイ情報を入力)
• Name server address 　(同上、プライマリDNSを入力)
• Hostname　　　 (自分できめたホスト名を入力）
• Domein name　 (自分できめたドメイン名を入力）

3. Set up users and passwords　(以下、自分で決めた内容を入力）

• Root password
• Re-enter password to verify
• Full name for the new user
• Username for your account
• Chose a password for the new user
• Re-enter password to verify

4. Partition disks

• Partitioning method (以下、３択：私はディスク全体に対しガイドによるパーティショニングを行う 'Guided - use entire disk'を選択）
  　　'Guided - use entire disk'
  　　 'Guided - use entire dis and set up LVM'
  　　 'Manual'
• Select disk to partition (以下、１択）
  　　 'Virtual disk 1 (vda) .... '
• Partitioning scheme (以下、３択：詳細は前述ガイドを参照願います。All filesが推奨とのこと。私は/homeを選択）
  　　'All files in one partition'
  　　'Separate /home partition'
  　　'Separate /home, /var, and /tmp partitions'
•  Finish partitioning and write changes to disk
  　　'Write the change to disk? (よければ、Yes )'

5. フォーマットとインストール

　上記メッセージ後、マーマットが開始され、しばらくしてインストールが開始され、以下、表示で完了

• Finish the instllation (Continue押下）
• バージョンの確認
  

  $ cat /etc/debian_version
  8.6

sudoのインストールと設定

sudoとは

sudo（“su do”）は、UNIXおよびUnix系オペレーティングシステムのプログラムの1つで、ユーザーが別のユーザーの権限レベルでプログラムを実行するためのコマンドである。一般的に、ユーザーがスーパーユーザー（superuser、すなわちroot）の特権レベルを利用する際に用いられることが多い。デフォルトではその別ユーザーのパスワード入力を求めてくるが、設定を変更すれば root のパスワードを求めるようにもできるし、端末（や擬似端末）につき1回だけパスワードを入力すればよいようにも、全くパスワード入力を求めないようにもできる[4]。sudo は各コマンド実行を記録でき、スーパーユーザーとしてのログインの完全な代替として使う場合もある。

　　（「sudo - Wikipedia」より引用）

sudoのインストール

1. rootにスイッチユーザ 
　　`$ su -`

2. sudoパッケージのインストール 
　　`# apt-get install sudo`

3. sudoユーザ設定

　sudo の設定ファイルである  /etc/sudoers を編集し、 ルート権限でコマンドを実行できるように設定。編集するためのコマンドと設定の内容は以下。

　　`# visudo`

    と入力し、「この位置」まで矢印キーで移動。
　　`# This file MUST be 以下省略...
　　# See the man page for details on 以下省略...
　　Defaults env_reset
　　# Host alias specification
　　# User alias specification
　　# Cmnd alias specification
　　# User privilege specification
　　root ALL=(ALL) ALL
　　「この位置」

　この位置のところで、以下の書式で追記。
　ユーザ名 ホスト＝権限 コマンド
　例（user1に権限付与）：
　　user1 ALL=(ALL)ALL

　CTL-Xでvisudoを抜ける。

　［上記以外に、作成したユーザをwheelグループに追加する手順もあり。〕

sshのインストールと設定

sshとは

ssh（Secure Shell：セキュアシェル）は、暗号や認証の技術を利用して、安全にリモートコンピュータと通信するためのプロトコル。

sshについて、その概要、認証方式、sshコマンド等について、以下のサイトで包括的にまとめられています。（導入前に一読をお薦めします。）

インフラエンジニアじゃなくても押さえておきたいSSHの基礎知識 - Qiita

sshの導入

1. サーバ側へsshパッケージをインストール

以下、コマンドでサーバへインストール実施。

　$ sudo apt-get update
　$ sudo apt-get install ssh

2. Mac側でキーペアを作成しサーバ側へ公開鍵を送り込む

  (1) 保存場所を作成
　　　$ mkdir ~/.ssh

  (2) 鍵の作成

           $ cd .ssh
           $ ssh-keygen

  (3) 作成した公開鍵をサーバ側へ送り込む
           $ scp id_rsa.pub ユーザ@サーバIPアドレス:~/

3. サーバ側で送り込まれた公開鍵を登録する

   (1) 準備

　　　$ cd ~
　　　$ mkdir .ssh
　　　$ chmod 700 .ssh/

　(2) 鍵の登録
　　　$ cat id_rsa.pub >> .ssh/authorized_keys
　　　$ chmod 600 authorized_keys

　(3) サーバーにコピーした鍵は削除
　　　$ rm id_rsa.pub

4.  Mac側からパスワード無しでログインできるかチェック

　　　ログイン状態であれば一旦、ログアウト。

　　　$ ssh ユーザ名@IPアドレス

　　　自動的にログインされることを確認。

5. セキュリティ上の対応

　サーバ側で、以下の設定変更実施。（設定内容は、/etc/ssh/sshd_config）

　　portの変更、rootログインの禁止、パスワード認証の禁止 

　(1) オリジナル設定内容のバックアップを取る

　　　$ sudo -s

           # cd /etc/ssh/

           # cp -p sshd_config sshd_config.org 

　(2) sshd_configをviで変更

　　　# vi sshd_config

          変更内容は以下のとおり。

　　　Port 22

　　　　→ 　22 を自分できめた番号(適当な数字:1024~65535の範囲で)に変更

　　　PermitRootLogin without-password

           (root でのログインの許可/禁止）

　　　　→　PermitRootLogin no に変更（Rootログインを禁止する。）

　　　ChallengeResponseAuthenticate no
　　　（チャレンジレスポンス認証を許可するかどうかを指定。
　　　　ログインを公開鍵認証だけにする場合、noに指定。）

　　　　→　no なのでこのままでok（チャレンジレスポンス認証を許可しない）

           #PasswordAuthentication no
　　　（パスワード認証の許可/禁止の設定。）

　　　　→　#を外す。
　　　　　（noとなり、パスワードログイン禁止、公開鍵でのログインのみ許可。）

　(3) sshサーバーを再起動

         # service sshd restart

    (4) Mac側からsshで接続

         $ ssh ユーザ名@IPアドレス

　　　--> エラー：ポート番号を指定しないとConnection refusedを確認

　　 $ ssh -p ポート番号 ユーザ名@IPアドレス

　　　--> OK

        $ ssh -p root@IPアドレス

　　　--> エラーログインできない：Permission denied

参考

4.2. インストール作業の各段階

VPSその2・さくらVPSにDebian 8をインストールする

へなちょこlinuxer » Debian 6 サーバー構築 » Debian6 インストール

sudo を使うには

sudo の設定

http://yaoshisi.herokuapp.com/tags/SSH/

さくらのVPSで最初にやっておくこと - 飲んだり寝たり

sshd_config＆PAMの設定 | OpenGroove

日本シーサート協議会 SSH サーバセキュリティ設定ガイド Ver 1.0 　　       ( http://www.nca.gr.jp/imgs/nca_ssh_server_config_v01.pdf )

複数バージョン共存可能なRails環境の構築

目的

• Ruby環境はrbenvを使用し、複数のバージョンを切替え可能とする。
• Bundlerを使用し、Railsをローカルディレクトリにインストールし、複数のバージョンのRailsプロジェクトの作成、共存を可能とする。

Rubyのインストール

rbenv とは

Rubyを管理するツール。複数バージョンのRubyの管理/切替えができる。

rbenvのインストール

Homebrewでインストール実施。

 (Xcodeインストール -> Command Line Tools for Xcodeインストール -> Homebrewインストール済）

• 最新パッケージリスト取得
  $ brew update
• rbenvのインストール
  $ brew install rbenv
• バージョンを確認
  $ rbenv -v
  rbenv 1.0.0

尚、ruby-build(rubyをビルドインするプラグイン)は、rbenvインストールでインストール済み。インストールする場合は、以下。(インストール済みの場合は、already installedと表示。

• ruby-buildのインストール
  $ brew install ruby-build
• バージョンを確認
  $ ruby-build --version
  ruby-build 20160602

PATHを通す

ターミナルへrbenvを使用するためのPATH設定を行う。

$ touch ~/.bash_profile

$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile

$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile

$ source ~/.bash_profile

最新のRubyをインストールする

rbenvからインストール可能なRubyのバージョンを確認

$ rbenv install -l

最新が 2.3.1 であることを確認。

現状MacBookにインストール済みRubyバージョンを確認

$ ruby -v

ruby 2.0.0であることを確認。

最新バージョン 2.3.1をインストール

$ rbenv install 2.3.1

デフォルトで利用するバージョンを指定

$ rbenv global 2.3.1

$ ruby -v

ruby 2.3.1であることを確認

インストールディレクトリ確認

$ which ruby

~/.rbenv/shims/ruby

Railsチュートリアルで使用するバージョン2.2.1をインストール

$ rbenv install 2.2.1

インストール済みで利用可能なrubyのバージョンを確認

$ rbenv versions

2.2.1 と 2.3.1 が表示されていることを確認。

system
2.2.1
* 2.3.1

ローカルディレクトリにRails環境を構築

ワークスペース用ディレクトリの作成

Railsプロジェクト用のワークスペースディレクトリを作成。

(Railsプロジェクトは今後、~/rails_wkspディレクトリ下に作成予定のため)

$ mkdir ~/rails_wksp

$ cd ~/rails_wksp

Railsチュートリアル実施用ディレクトリ作成

※新規Railsアプリケーション開始時は基本的にここから実施。（別バージョンのRubyを使用する場合は、Rubyのインストールから実施。）

Railsチュートリアル実施のため、Railsアプリケーションを開発するためのディレクトリを作成。この環境にRuby2.2.1を適用。

$ mkdir ~/rails_wksp/sample_app

$ cd ~/rails_wksp/sample_app

以降、本ディレクトリで作業実施。

使用するRubyのバージョン 2.2.1を指定。

$ rbenv local 2.2.1

$ ruby -v

ruby 2.2.1を確認。

$ rbenv versions

以下を確認。

system

* 2.2.1

  2.3.1

Bundlerをインストール

Railsで使用するGemを各プロジェクト毎に管理するため、bundlerのインストールを行う。bundlerはgemの管理システムであり、bundler自体もgemの一種。

RubyGems => gemをインストールするためのアプリケーション(ただしシステム全体に影響してしまう)
bundler => プロジェクトごとに使用するgemやgemのバージョンを設定できる(システム全体に影響しない)

$ rbenv exec gem install bundler

Successfully installed bundler-1.13.6

$ rbenv rehash

Bundlerを使用し一時的にrailsをローカルにインストール

Railsアプリケーションを作成するために一時的にrailsをローカル（sample_app下）にインストール。

• Gemfile作成
  どんなRubyのライブラリ(gem)を使うのかを示すGemfileを作成
  $ rbenv exec bundle init
  作成されたGemfileをの「# gem "rails"」の箇所をエディタで変更
  

  source "https://rubygems.org"

  # gem "rails"
  チュートリアルで使用するRailsのバージョン4.2.2を使用するよう以下に変更。
  gem "rails", "4.2.2"
  
  

• Railsのインストール実施
  $ rbenv exec bundle install --path vendor/bundle
  Installing rails 4.2.2
  Bundle complete! 1 Gemfile dependency, 35 gems now installed.
  Bundled gems are installed into ./vendor/bundle.
  補足：オプション「--path vendor/bundle」を付けることによりgemは、アプリケーション限定の領域(vendor/bundleディレクトリ）にインストールされる。（オプションがない場合、Mac全体で共有される領域にインストールされる。）
  システム全体で共有される領域へgemをインストールしても、管理されていれば基本的に問題はないが、依存問題等のリスクを考慮し、アプリケーション毎に隔離独立していることを担保することとした。
• 以下作成を確認
  

  $ ls

  Gemfile Gemfile.lock vendor
  補足：vendorディレクトリ下に、「vendor/bundle/ruby/2.2.0」のファイルがあるが、末尾のバージョン(tiny)は無視されているようですので、2.2.0 〜 2.2.x でも .../2.2.0 になる模様。

Railsアプリケーションの新規作成

先にbundleでインストールしたgemパッケージを利用し、Railsアプリケーション「sample_app」を作成。なお、すでに作成済みの「sample_app」ディレクトリをアプリケーション名とするので、「rails new アプリケーション名」は「rails new .」とする。

• Railsアプリケーションの新規作成
  $ rbenv exec bundle exec rails new . --skip-bundle
  先に一時的に同一ディレクトリでrailsをインストールしているため、以下のようにGemfileの上書きの確認がされるが、許可を実施。
  

      conflict  Gemfile

  Overwrite /Users/s-asano/rails_wksp/sample_app/Gemfile? (enter "h" for help) [Ynaqdh] Y

         force  Gemfile

  補足：bundleでインストールしたgemパッケージを利用するため「bundle exec」というプレフィックスを指定。そして、bundle installが発動し現在有効なrubyにrailsがインストールされないよう「--skip-bundle」オプションを指定。（後述の「Railsアプリケーションの環境セットアップ」で実施。）
• 以下、生成を確認。
  

  $ ls

  Gemfile Rakefile config lib test

  Gemfile.lock app config.ru log tmp

  README.rdoc bin db public vendor

Railsアプリケーションの環境セットアップ

• 必要に応じてsample_appのGemfileの内容を編集
• Railsの標準gemのインストール実施。「--path vendor/bundle」オプションをつけ、アプリケーションに閉じた状態でGemをインストール
  $ bundle install --path vendor/bundle
  Installing rails 4.2.2
  Bundle complete! 12 Gemfile dependencies, 56 gems now installed.
  Bundled gems are installed into ./vendor/bundle.
  これにより、Rails(及び関連Gem)が、新規作成Railsアプリケーションのvender/bundleディレクトリ以下にインストールされる。

Railsアプリケーションの起動

• Railsアプリケーションを起動
  $ bundle exec rails server
  ＊railsやrakeといったコマンドを実行する際は、bundle exec を介する必要がある。
• ブラウザを立ち上げ、アドレスバーに「http://localhost:3000」を入力しRailsの初期画面が表示されることを確認。
  

  
  

その他

Gitの管理対象について

容量、復元の容易さの観点から、vendor/bundle ディレクトリはGitの管理対象から を外す。

全てのgemのアンインストール方法

$ gem uninstall -axI `gem list --no-versions | egrep -v 'test-unit|rdoc|psych|minitest|io-console|rake|bigdecimal|json'`

不要になったRubyのアンインストール

$ rbenv uninstall -f 2.2.1

$ rbenv rehash

参考サイト

以下のサイト様の情報を参考にさせていただきました。感謝いたします。

• Mountain Lion に rbenv を導入 - hrysd の旧ブログ

• 【El Capitan】Mac OSX 10.11 El Capitan にRuby + Rails4 開発環境の構築 【初心者必見】 - Qiita

• 【Mac】初心者向けRuby on Rails環境構築ガイド【El Capitan対応】 - Qiita

• PATHを通すために環境変数の設定を理解する (Mac OS X) - Qiita

• Rails開発環境の構築（複数バージョン共存可能）（Homebrew編） - Qiita

• MacにRuby on Railsをインストールする | CodeNative

• Ruby on Rails 導入方法【初級編】 - 技術ブログ | 株式会社クラウディア

• Rubyのgemを全てアンインストールする

ターミナルの基本

ターミナル(黒い画面[Macデフォルト白い画面])とは

「ターミナル (Terminal) は、アップルのOS Xに標準で付属しているUNIX端末エミュレータ。ターミナルを起動すると、UNIXとしてのOS Xの標準CLIシェルであるbashが起動し、UNIXコマンドを打ち込むことができる。」(Wikipediaから引用)

「bash （バッシュ）は UNIX で使用するシェルのひとつ。bash の名前はBourne-Again Shellの頭字語。」(Wikipediaから引用)

シェル(Shell)：OSの内部(カーネル)の外側にある殻。各種サービスを行っているユーザインターフェース。

基本事項

ターミナルの仕組み、本質がすごくわかりやすく以下に書かれています。

Webデザイナーの為の「本当は怖くない」”黒い画面”入門 Part.01 « FJORD, LLC

以下は、エッセンスだけ、頭の整理、備忘として引用させていただき、書き留めます。

コマンド

”黒い画面”ではファイル名を入力することでプログラムを実行する。（”黒い画面”は所詮はプログラムのファイル名を打ち込んでいるだけ）

PATH

PATHは”黒い画面”に設定されている項目の一つで、ここにディレクトリ名を設定しておくと、そこの中にあるプログラムはディレクトリ名を省略してファイル名だけで実行できる。PATHのお陰で見た目上コンピューターに正にCommand(指令)を送っているように見える。

コマンド ls 「一覧(list)を表示せよ！」

$ ls
Applications Documents Library Music Public
Desktop Downloads Movies Pictures

実体は、/bin/ls ファイル名を打ち込んでいる。

引数とオプション

引数はコマンドに渡す文字列。コマンドの後にスペースを一個いれて文字を打ち込む。引数はスペースで区切って複数渡すことができる。引数をどう処理してくれるのかはコマンドによって異なる。

引数の中で特に-(ハイフン)から始まっているものをオプションという。

作業の自動化

“黒い画面”での作業は文字を打ち込むだけの単純で厳密な手順なので簡単に自動化できる。（黒い画面で打つコマンドをそのままファイルに書くだけで自動化が可能。）

　例：以下を自動化

　　　$ mkdir bar
　　　$ cp file1 bar/file1

• 黒い画面で打つコマンドをそのままファイルに書く。mycopyファイルの中身
  mkdir bar
  cp file1 bar/file1
• そのファイルを実行するにはshコマンドに渡す。$ sh mycopy

謎のおまじない”シバン”

“黒い画面”にはスクリプトを単体で実行するためにshebang(シバン：sharp bang)という機能あり。（「”黒い画面”で実行しようとしたファイルの1行目の最初の二文字が#!だったら、その後に書いてあるコマンドに2行目以降の全てを渡す」）

　例：mycopyにシバン追記（１行目の#!）

　　　　#!/bin/sh
　　　　mkdir bar
　　　　cp file1 bar/file1

　　　mycopyのファイル権限を変更し、$ mycopy　で実行

 shebangを利用すれば様々なスクリプトを単体で実行できる独自のコマンドにすることが可能。 

参考サイト

• Webデザイナーの為の「本当は怖くない」”黒い画面”入門 Part.01 « FJORD, LLC

怖話をひと通り使った感想と改善案 (3)

使用環境：PC(ブラウザChrome)、iPhoneアプリ、Androidアプリ

確認サイト：怖い話投稿サイト 怖話（こわばな）

ナビゲーションについて

感想

グローバルナビゲーションが横に長く、全画面表示でも全てが表示されないので集約等して収まるようにした方が良いのではないかと思いました。

（ショップ、マイページが見えない状況なので。スクロールすれば見れるのですがどうかなと、、ちなみにディスプレイは13inchです。）

Chromeのズーム80%で全て表示。

改善案

現在１７個のメニューがありますが、内容をカテゴライズすると、大枠で以下の７つになるかと思います。

ホーム、ニュース、ランキング系（アワード・怖話オブザイヤー）、怖い話のコンテンツ系（怖い話・都市伝説～悪魔、心霊スポット）、掲示板、ショップ、マイページ。

メニューを集約し、カテゴリ内のメニューはドロップダウンメニューにしたらどうでしょうか。

《私の感じた問題点と改善案》

1. 目的ページへの効率性（目的のページまで容易にたどり着けるか）

　表示設定によっては、全画面でも見えないメニューがあり、訪問者によっては戸惑う場合があるのではと思いました。

=> メニュー案として以下を考えました。括弧［ ］内はドロップダウンメニューに配置。尚、心霊スポットは話系と違い、外に向かうアクションにつながるかと思いメインメニューに配置。また、「使い方」のページと補助ナビ（ページの最下部）はありますが、メインメニューに、怖話サイトの魅力、使い方を伝える「怖話ツアー」を配置されてはと思いました。グローバルナビゲーションの９つのメインメニュー構成案を以下に記載します。

ホーム、怖話ツアー、ニュース、アワード［ 月間アワード・怖話オブザイヤー］、怖い話［ 怖話・都市伝説、ホラー漫画、オーパーツ～悪魔］、心霊スポット、掲示板、ショップ、マイページ

　-> css、viewの見直し。

 マイページについて

感想

「第三者から見たあなたのページ」が確認できるのは個人情報保護の観点で安心感があり、良いと思いました。ただ、更新した後、「第三者から見たあなたのページ」がすぐには把握できないので（マイページ -> 自分のページ とたどり、確認することはできますが）、更新後のレスポンスで表示され、すぐわかればと思いました。

また、更新する時点で、表示するか、非表示とするかの選択を、「性別」、「年齢」については、選択ボタンがあります。ただ、職業、都道府県等がないので同様に選択できるようにしたらと思いました。（都道府県については、都道府県を選択したら表示、職業も記載したら表示［要は記載された内容が表示］という意味では、表示非表示を選択できるとも言えますが）

改善案

1. 情報の優先性（各ページのレイアウトがユーザにとって妥当か）

登録情報更新後の「第三者から見たあなたのページ」の把握を容易にする。

=> 更新の応答画面に「第三者から見たあなたのページ」を表示する。

　-> viewとcontrollerの見直し

2. デザインルールの一貫性（レイアウトの導線に一貫性があるか）

更新項目について、表示、非表示を明示的に選択できる項目とそうでない項目があるが、全て明示的に選択できるようにしたらと思いました。

=> 各項目に、表示、非表示のラジオボタンを配置し、選択できるように明示する。

 iPhoneアプリでの確認

感想と改善案

PCでの操作、表示感を踏まえ、 iPhoneアプリで怖話をひと通り使った感想について、PC未記載について記載します。

1. 全体的に分かりやすく、操作しやすいと思いました。また、アプリのアイコンも「怖い話」から連想するオドロオドロしさがなく、すっきりと収まりが良く感じ、個人的にはすきです。

2. homeページについて、コンテンツ枠について、PCでは３列（「怖い話」は３列２段）で表示されているものが、横一列に表示されています。画面を右方向にスワイプすると見ることができるのですが、その行だけ、ズルズルと表示されるので、少し違和感を感じました。画面の枠の範囲で縦に表示されては思いました。（後述のAndroidではそのように表示されていました。）

尚、上記の状態なので、画面を縦にスワイプして見た場合、コンテンツが１に対し、広告はPCと同様、縦にコンテンツ枠と同じ大きさでズルズルと表示されるので、広告の表示比率が非常に高く、多少しつこさを感じました。

=> home画面について、コンテンンツの表示を画面枠で縦に表示。

　-> viewとcssの変更。 

Androidタブレット(7inch)アプリでの確認

感想と改善案

iアプリとアイコンが違っていたので一瞬、「怖話」とは別のものかと思いました。同じデザインが良いかと思いました。（ちなみに、iアプリのアイコンの方が、個人的にはすきです。）

home画面について、Androidではiアプリのようなことはなく、コンテンツ枠にコンテンツが縦に並び、横にスワイプするようなこともなく、違和感はありませんでした。閲覧視聴もスムーズで特に、改善を、と、いったことはありませんが、アプリの紹介文で「15,000以上」の記載がありますが、最新の「20,000件以上」か、検索で表示される「18,000以上」に統一し、見直されたらと思いました。

1. アイコンの統一

=> iアプリとAndroidでアイコンが違うので統一する。

　-> アイコンの変更登録。

2. 紹介文の統一

=> 収録話数について、最新の話数、「20,000件以上」に統一する。

　-> 紹介文の変更登録。

その他、ショップについて 

今、まさに、 ハロウィンの時期なので、ショップもシーズンに合わせたものにする等をされたらと思いました。

怖話をひと通り使った感想と改善案 (2)

使用環境：PC(ブラウザChrome)

確認サイト：怖い話投稿サイト 怖話（こわばな）

怖話会員登録について

感想

SNSからの連動、個人情報取扱に関する注意書きもあり、簡単、かつ、分かりやすいインタフェースと感じました。

ただ、登録に使用したメールアドレスが、本人所有のものかを確認する、アカウントの有効化 (アクティベーション: 新規ユーザーのメールアドレスが有効であることを確認する)機能はないので、セキュリティの観点から、 アカウントのアクティベーション機能を実装されてはと思いました。

改善案

登録したEmailが本人のものかどうかを確認した後、アカウントを有効にするようにする。

《私の感じた問題点と改善案》

1. セキュリティへの配慮

(1) 架空、本人以外のEmail登録でアカウント開設が可能になることに伴うリスクがないとは言えないと思いました。

=> アカウント・アクティベーション機能（登録されたEmailにアクティベーションURLを送付し、登録者が確認、クリックすることで本人確認を行い、アカウントを有効化する機能）を実装する。

　-> 同様の機能がパスワード再設定において既に実装されているので、会員登録においても同様に、実装する。

パスワード再設定について

感想

パスワード再設定において、アクティベーション機能（入力したEmailにアクティベーションURLを送付し、登録者が確認、クリックすることで本人確認を行い、パスワード再設定に進む）が実装され、送信されたメールも分かりやすいと感じました。

ただ、アクティベーションURLの有効期限の記載がなかったので、セキュリティ上の安心感として、有効期限があるようであれば記載、ないようであれば実装されてはと思いました。

改善案

セキュリティ上の安心感、リスクの低減の目的で、アクティベーションURLの有効期限について考慮してはと思います。（実装済みであればご容赦願います。）

《私の感じた問題点と改善案》

1. セキュリティへの配慮

(1) 有効期限有無に伴うリスクの懸念。

=> 有効期限があるようであれば記載、ないようであれば実装(送信したURLの有効期限をチェック）する。

　-> 有効期限のメールへの明記、サーバ側で送信時刻を保持し、クリック（リクエスト）された時刻とチェックし、有効期限内かどうかをチェック。

アワードと怖話オブザイヤーのページについて

感想

アワードと怖話オブザイヤーのカテゴリは「ランキング」という意味で同じ括りかと認識しますが（もし認識相違でしたらご容赦願います）、その認識に立った場合、トップナビゲーションが別立て（「アワード」「怖話オブザイヤー」）で設定されていることに個人的に多少違和感を感じました。

それと、怖話アワードと怖話オブザイヤーには「ランキングにより決定」の旨の説明がありますが、「特選」についての説明がないのが気になりました。（私の見落としでしたらご容赦願います。）

改善案

ナビゲーションの観点、ページ内容の明確性の観点、デザインルールの統一性の観点から感じましたことを以下、改善案とともに記載させていただきます。

《私の感じた問題点と改善案》

1. ナビゲーションの直感性（ナビゲーションの使用方法がざっと見ただけで理解でき、コンテンツの移動、バック、homeへの移動が速やかに行えるか）

(1) アワードと怖話オブザイヤーのカテゴリが「ランキング」という意味で同じ括りと認識した場合、好みの問題に過ぎないと思いますが、ナビバーが横に長いこともあり、共通的括りを表すナビゲーション名に集約したらと思いました。

=> トップのナビバーは「ランキング」とし、ドロップダウンで「月刊アワード」「怖話オブザイヤー」「特選」とされてはと思いました。

　-> viewとcssの変更

2. ページ内容の明確性（ひと目でページに記載されている内容を理解できるか）

(1) 「特選」の表示画面において説明がないので（見落としでしたらご容赦）、何を持って特選としているかわかりませんでした。（訪問者が、ん？とならないかと、）

=> 特選についての意味合い等の説明文を記載する。

　-> 該当表示viewに説明文を追記。

3. デザインルールの一貫性（レイアウトの導線に一貫性があるか）

 (1) アワードと怖話オブザイヤーでサブナビの表示とデフォルト表示が異なっている。過去の経緯か意図的なことなのかよくわかりませんが、個人的には一貫性の観点から同じで良いように感じました。

　アワード初期表示（√が初期表示）

　　現在の順位　√受賞作品一覧　過去の順位

　怖話オブザイヤー（√が初期表示）

　　√現在の順位　過去の順位

=> アワードと怖話オブザイヤーとも、√現在の順位　受賞作品一覧　過去の順位 とする。

　-> 表示viewとデータセットを行うcontrollerの修正。

ニュースページについて

感想

日付とタイトルだけなので、個人的には、多少、味気なく感じました。

リード文を付加する、あるいは、カテゴリ（地域、種類［イベント、映画、告知etc］等）選択ボタンを表示する等をされてはと思いました。

また、触ってみて、「コメント」ボタンと表示について、これはどういう意味だろう、これは何だろうといった（私だけかもしれませんが）戸惑ったところも幾つかありました。具体的には各改善案記載の通りです。

改善案

各ニュース欄の視認性向上のためのリード文追加、古いニュースのアーカイブ化、サブナビゲーションボタンの直感性等、改善案を検討しました。

《私の感じた問題点と改善案》

1. ページ内容の明確性（ひと目でページに記載されている内容を理解できるか）

　日付とタイトルだけなので、欲しい情報があるのかないのかをパッと見での把握がしにくいと感じました。

=> 新たにリード文を起こすのは現実的でないため、記事の冒頭数行をリード文として、ニュース一覧の各記事のタイトル下に表示するようにする。文字数を超過する場合は「•••続きは=>」とか表示して。

　-> viewの変更

2. 通常のサイトチェック事項（リンク切れ、古い情報の放置有無、削除もれページ有無）

　最近の情報、過去情報がすべて同列でずらずら出ているので、一年以上前のデータは年毎のアーカイブとするとかをされた方が、（個人的に感じたことですが）放置感がなくて良いのではないかと思いました。

=> １年以上前のニュースはサイドバーで年毎にアーカイブし、メインレイアウトからは外す。

　-> css、views、controllerの見直し。

3. ナビゲーションの直感性（ナビゲーションの使用方法がざっと見ただけで理解できるか）、ページ内容の明確性（ひと目でページに記載されている内容を理解できるか）

(1) 怖話ニュースページに「コメント」ボタンがついています。パッと見、個々のニュースに対するコメントを発信するための機能かと思いましたが、コメント一覧を表示するボタンだったのですね。実際にコメントを投稿してわかりました。そういう意味で、パッと見、少しわかりにくく感じました。

=> ボタン名を各々、「ニュース一覧」と「コメント一覧」に変更してはどうかと思いました。

　-> view、ボタン名の変更

(2) それと、各欄下部の青字行は「ニュース」のタイトルを表示しているわけですが、パッと見、それがわからず、このコメント一覧は、何のコメント一覧を表示しているのか、（私だけかもしれませんが、）多少戸惑いました。青字の一行はニュース一覧の表示内容と同じもの「お知らせ 16/09/26 怖話グッズの販売を開始しました!!」（分類マーク：発信日：タイトル）を表示されてはと思いました。

=> 各欄下部の青字行をニュース一覧表示と同内容にする

　-> viewとcontrollerの変更

怖い話のページについて

感想

サイトのレイアウト構成、操作に慣れてきた関係もあるかもしれませんが、戸惑い、違和感等はなく、表示の切り替え、各種効果等、わかりやすく、楽しめるようになっていると思いました。今後は動画（怖話レポート、怖い話の朗読等）も取り扱えるようになったら面白いように思いました。

なお、作品表示画面ですが、各ボタン等にマウスをのせると説明文が表示される等があればと思いました。私だけかもしれませんが、大きいボタンの「怖い５」とその下の表

中の怖い「５」のボタンの違いが、同じ「怖い」ということもあり、パッと見、わからず、ページ下部にある「怖話の使い方」を見てわかりました。（とにかく押せばわかる、のかもしれませんが、、）

改善案

パッと見、パッと触り、すぐわかる、という点で、ボタン等について、マウスオーバ時、簡単な説明文が表示されればと思いました。

1. ユーザ補助への配慮（利用しやすいように補助する機能があるか)

　ボタン押下時の意味合いをガイドする簡単な説明を表示する。

=> 大きなボタン「怖いn」にマウスが乗った時は「怖いに投票」、下表怖いの「数値」にマウスが乗った時は「怖い投票をした読者覧へ」

　-> ボタンにtitle属性を設定するようviewを変更。

都市伝説〜心霊スポットのページについて

感想

怖い話とほぼ同様の構成で感想、改善案も怖い話と同様です。

ただ、投稿について、「怖い話」が効果挿入等、てんこ盛りなのに対し、他のカテゴリには組み込まれていなくて、なぜかなと思いました。あまり要望がないのかもしれませんが。

参考

確認観点の洗い出しに際し、「Webディレクション標準ガイド 第二飯」を参考にしました。

怖話をひと通り使った感想と改善案 (1)

使用環境：PC(ブラウザChrome)

確認サイト：怖い話投稿サイト 怖話（こわばな）

homeページについて

感想

ページの半分以上に記事と同枠で広告(?)が貼られていて、一瞬、何のサイトかと思った。「その抜け毛、待った無し！」確かに、怖い話ではありますが、、

全く同じ広告が２つ貼られているのも気になりました。

 改善案

サイト訪問者が最初に目にするページなので、何のサイトか一目でわかるようなキャッチコピー、紹介文、目的ページへの導線等を配置した方が良いように思いました。

また、広告（広告と思いましたが、実は記事？）は、下部かサイドバーに配置する等、コンテンツの枠とは分けた方が良いように思いました。

《私の感じた問題点と改善案》

1. ページ内容の明確性（ひと目でページに記載されている内容を理解できるか）

(1) 広告が画面の大半を占め、また、サイト紹介文がページの下の方にあり、何のサイトがわかりにくい。

=> ページの上部に、キャッチコピー、紹介文を配置する。

　-> 対応：cssとviewsの対応と想定します。

2. 情報の優先性（各ページのレイアウトがユーザにとって妥当か）

(1) 広告がコンテンツと同じ枠にあり、多少混乱した。（実は「その抜け毛、待った無し！」を怖い話のコンテンツかとも思い、クリックしてしまいました。［意図的な配置でしたら私の勘違いであり、ご容赦願います。］訪問者にとって情報の優先性の観点からどうかと思いました。）

=> コンテンツ枠と広告枠は（例えばサイドバーに配置する等）分ける。

　-> 対応：cssとviewsの対応と想定します。

 3. その他

(1) 同じ広告が複数掲載されていて気になりました。（「その抜け毛、待った無し！」は５個。ちなみに私は、幸いなことに、抜け毛の悩みはありませんが、サイト管理という意味で気になりました。）

　また、homeページには、広告表示ブロックが３個あり、各ブロックの表示内容がほぼ同じ、（訪問者から見れば、同じ広告を３回（各ブロックに重複してあれば、５、６回）目にすることになり、どうかと思いました。

　それと、各コテゴリページも同様の構成になっており、個人的には多少のしつこさを感じました。（そういう意味でも広告はサイドバーあたりに配置し、広告掲載場所だから当然同じか、と、いった感じに思うような配置が良いように思いました。）

=> 広告掲載管理を行い、同じ広告内容のものは載せないようにする。

　-> 対応：運用。タイミングで広告内容が変わっているので仕組みがまだ見えません。

(2) 紹介文に「怖話は18000話以上の怖い話がある世界最大の怖い話サイトです。」との記載があります。サイトトップに「20,864話」(確認時点)とあり、本文も、「怖話は20,000話以上の〜」に更新されたらと思いました。

=> 紹介文を更新する。

　-> 対応：コンテンツ、viewsの対応と想定します。

コンテンツページ一覧（怖い話、都市伝説等）について

感想

ページネーションがないので、各コンテンツに幾つ掲載されているか、自分がどのあたりにいるかわからず、見通しが悪いように感じました。それと広告の話で恐縮ですが、「現在の順位」ナビバーと広告がくっついているため、一瞬、怖話アワードの一位が「気休めの育毛剤はもう終了」かと思ってしまいました。

また、大量のコンテンツがある中、分類分けがないので見たい情報にたどり着くのが大変なのではと感じました。

 

改善案

コンテンツのページは見たい情報に早くたどりつきたい、把握したい、今どのあたりを見ているのだろう、といったところが、訪問者にとって期待したいユーザビリティのように思いました。

《私の感じた問題点と改善案》

1. 目的ページへの効率性（目的のページまで容易にたどり着けるか）

　カテゴリ内（怖い話、都市伝説、ホラー漫画等々）のコンテンツに分類分けがないので、全てのページをスクロールで見ていく必要があり、目的ページへ効率的にたどり着くという点でどうかと思いました。

=> 各カテゴリ毎に小分類を設ける。例えば、オーバーツであれば地域別等。

　-> カテゴリ情報を投稿テーブルのカラムに持ち、情報取得のメソッドをモデルに記述。表示viewの変更、controllerで情報をセット、が対応内容と想定します。

2. 現在位置の確認（常に自分の位置を把握できるか）、ユーザ補助への配慮（サイトを利用する上で閲覧を断念させる問題点がないか、利用しやすいように補助する機能があるか）

　スクロールによる表示のため、各カテゴリにどれだけのボリュームのコンテンツがあるかわからないため、先の見通しが立ちにくいと感じました。

=> ページネーション機能を導入する。

　-> kaminariかwill_paginateを導入。gemfileの追加、controllerとviewに追記と想定します。

投稿表示ページについて

感想

投稿をクリックすると投稿内容が表示されますが、投稿内容と投稿者、投稿日時の間に、広告、その他の情報が挿入されていて、投稿内容を読んでいて、「この投稿、いつだれがしたのだろう、どこに掲載されているだろうと」少し戸惑いました。

投稿内容と投稿者、投稿日時はセットの情報（何を誰がいつ）と思うので、ひとくくりに表示した方が良いのではないかと思いました。

《私の感じた問題点と改善案》

1. 情報の優先性（各ページのレイアウトがユーザにとって妥当か）

　投稿内容と投稿者、投稿日時の間に、広告、その他の情報が挿入されていて、情報のセット要素（5W1H）が分断され情報認識のしやすさという面でどうかと思いました。

それと、「作者のページ」となっていますが、「作者」は「投稿者」か「情報提供者」が妥当のように感じました。（作者だと、話を作った人のようなニュアンスを感じましたので。）

=> セット情報はひとくくりにする。具体的には、投稿内容の直下に情報提供者、投稿日時を配置する。

　-> viewの変更。

投稿者の情報ページについて

感想

一覧のボタンについて、動作を確認しましたが、少し戸惑いがありました。

具体的内容は「改善案」に記載します。

改善案

一覧ボタンの表示と動作について、「デザインルールの一貫性」「ナビゲーションの直感性」「バグ？」について、気づいた点の改善案について以下、記載します。

《私の感じた問題点と改善案》

1. デザインルールの一貫性（レイアウトの導線に一貫性があるか）

「投稿」枠に「一覧」と「全ての投稿を見る」の２つのボタンがありますが、どちらも動作は同じ（投稿者の全ての投稿一覧を表示）と思われ、「一覧」ボタンだけで良いのではないかと思いました。

=> 「全ての投稿を見る」ボタンを削除する。

　-> viewの変更。

また、「評価」枠の「アワード受賞数」に一覧のボタンがありますが、ボタンを押すと投稿者の受賞一覧ではなく、サイト全体の受賞一覧が表示されます。投稿者に関する情報のページなので、投稿者が受賞した投稿の一覧が表示されると期待しました。受賞がゼロの場合は、「一覧」ボタンを非表示にした方が良いのではないかと思いました。

=> 「一覧」ボタンで表示するのは当該投稿者の受賞投稿一覧とする。受賞投稿がない場合、「一覧」ボタンを非表示とする。

　-> controllerとviewの変更。

2. その他（バグ？）

「活動」枠に「怖いをつけた数」があります。バグではないかと思いますが、下記ではその値が４となっていますが、一覧ボタンをクリックすると１件でした。

=> 値か一覧の表示内容のどちらが正しいか確認し、整合と取る。

　-> 不具合各所の修正。controllerのロジック不具合かと思いました。

本当にあった怖い話

実は、本ブログをアップしようとして、再度、サイト怖い話投稿サイト 怖話（こわばな）を確認すると、上記に記載していた、広告の表示が変わっていて、、

ん、、、

これって、怖くないですか、、

（後日談：当初、ログインしていない状態で確認していました。ログイン後とログイン前で違うようです。お騒がせしました、、）

参考

確認観点の洗い出しに際し、「Webディレクション標準ガイド 第二飯」を参考にしました。