2015年5月31日日曜日

rails4でbatchを作成する。 rspecでテストを実行

環境

rails(ruby2.2.2, rails4.2.1)アプリ

この記事で、バッチ処理をrailsで作成するやり方を書きました。
今回は、このコードをrspecでテストする方法を説明したいと思います。

テストコードのの作成

specフォルダの中にlibフォルダを作成します。
batchのテストは全てこのspec/lib/batch/*配下に作成することになります。


// プロジェクトルートに遷移
cd {prohject_root}

mkdir -p spec/lib/batch

touch spec/lib/batch/summary_spec.rb

ここではsummary_spec.rbというspecファイルを作成しました。

summary_spec.rbの実装


require 'rails_helper'

describe "Summary" do
  it "should be success." do
   // something
  end
end

require 'rails_helper'を記述します。これで、FactoryGirl等のrailsと同じテスト環境を利用できるようになります。

summary_spec.rbの実行

作成したsummary_spec.rbを実行します。


bundle exec rspec spec/lib/batch/summary_spec.rb

1 examples, 0 failures

上手く実行できました。

以上です。

参考サイト

rails4でbatchを作成する

この記事がお役にたちましたらシェアをお願いします

2015年5月30日土曜日

環境

rails(ruby2.2.2, rails4.2.1)アプリ

バッチ処理をrailsで作成しました。以下にやり方を記載します。

batchフォルダの作成

batchフォルダをlibフォルダ配下に作成します。
batchファイルは全てこのlib/batch/*配下に作成することになります。


// プロジェクトルートに遷移
cd {prohject_root}

mkdir -p lib/batch

touch lib/batch/summary.rb

ここではsummary.rbというバッチファイルを作成しました。

libフォルダを読み込む設定

config/application.rbファイルにlibフォルダ以下を読み込めるように設定します。


require File.expand_path('../boot', __FILE__)

require 'rails/all'

# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(*Rails.groups)

module Yamachennnel
  class Application < Rails::Application

    # batch path
    config.autoload_paths += %W(#{config.root}/lib)
  end
end

これでbatchフォルダ以下のファイルを読み込めるようになりました。

summary.rbを記述

作成したsummary.rbにバッチ処理を記述します。


# coding: utf-8
class Batch::Summary
  def self.execute
    "Hello world"
  end

end

上記の処理を実行します。


// プロジェクトルートに遷移
cd {prohject_root}

bundle exec rails runner Batch::Summary.execute

上記のコマンドでexecuteメソッドを呼び出すことができます。もちろんActiveRecoedも利用できます。
次はRspecを使ったテストコードの記載方法を説明したいと思います。
今回は以上です。

参考サイト

Rails4.0でcron(バッチ処理)を動かす設定

この記事がお役にたちましたらシェアをお願いします

chef(berkshelf)でelasticsearchをインストール

アプリにelasticsearchを導入したので忘備録的なメモ。
以前、この記事で利用方法をまとめましたが、こちらもナレッジを追加修正して随時更新していきます。
なお、今回elasticsearchの導入にはchefを使いました。

環境

rails(ruby2.2.2, rails4.2.1)
vagrant centOS6.5
chef11
elasticsearch1.5.2

berkshelf

Berksfileファイルに以下のcookbookを記載します。


cookbook 'elasticsearch'
cookbook 'java'

javaはversion8を使いたいので、cookbookに記載しました。version7で問題ない場合は、このcookbookは不要です。

berks vendor cookbooks


// 以前のcookbookは破棄する
rm -rf cookbooks
berks vendor cookbooks

roleの設定

role/elasticsearch.jsonを作成します。


{
  "name":"elasticsearch",
  "chef_type": "role",
  "json_class":"Chef::Role",
  "description":"tool server role",
  "run_list": [
    "recipe[java]",
    "recipe[elasticsearch]",
    "recipe[elasticsearch::plugins]"
  ],
  "default_attributes": {
    "java": {
      "install_flavor": "oracle",
      "jdk_version": 8,
      "java_home": "/usr/local/java",
      "oracle" : {
        "accept_oracle_download_terms": true
      }
    },
    "elasticsearch": {
        "version": "1.5.2"
    }
  }
}

elasticsearchは1.5.3を指定します。elasticsearch::pluginsでプラグインも指定しています。

pluginの設定

elasticsearchにはkuromojiを始めとして、様々なpluginが存在します。
これらのpluginを利用するために、installに必要な設定を記述します。


mkdir -p data_bugs/elasticsearch/

touch data_bugs/elasticsearch/plugins.json

plugins.jsonの記述

必要となるpluginを記載します。


{
    "id": "plugins",
    "_default": {
        "plugins": {
            "elasticsearch/elasticsearch-analysis-kuromoji": { "version": "2.5.0" },
            "royrusso/elasticsearch-HQ": {},
            "elasticsearch/marvel/latest": {},
            "polyfractal/elasticsearch-inquisitor": {}
        }
    }
}

chef-soloを実行

あとはいつも通りにchefを実行するだけです。


knife solo cook localhost

無事に実行が完了したら、localhost:9200に接続すると以下のjsonが表示されます。


{
  "status" : 200,
  "name" : "192.168.33.12",
  "cluster_name" : "elasticsearch",
  "version" : {
    "number" : "1.5.2",
    "build_hash" : "62ff9868b4c8a0c45860bebb259e21980778ab1c",
    "build_timestamp" : "2015-04-27T09:21:06Z",
    "build_snapshot" : false,
    "lucene_version" : "4.10.4"
  },
  "tagline" : "You Know, for Search"
}

続いてpluginのinstallを確認します。

urlにhttp://localhost:9200/_nodes/_all?plugin=true&prettyを指定します。


      // something(長いので省略) 

      "plugins" : [ {
        "name" : "analysis-kuromoji",
        "version" : "2.5.0",
        "description" : "Kuromoji analysis support",
        "jvm" : true,
        "site" : false
      }, {
        "name" : "marvel",
        "version" : "1.3.1",
        "description" : "Elasticsearch Management & Monitoring",
        "url" : "/_plugin/marvel/",
        "jvm" : true,
        "site" : true
      }, {
        "name" : "inquisitor",
        "version" : "NA",
        "description" : "No description found.",
        "url" : "/_plugin/inquisitor/",
        "jvm" : false,
        "site" : true
      }, {
        "name" : "HQ",
        "version" : "NA",
        "description" : "No description found.",
        "url" : "/_plugin/HQ/",
        "jvm" : false,
        "site" : true
      } ]

指定した4つのpluginがinstallされているのが確認できました。

以上

参考サイト

この記事がお役にたちましたらシェアをお願いします

2015年5月28日木曜日

jenkinsの導入 chefを使ってjenkinsを導入する

公開日：2015年05月28日

最近何度かjenkinsを構築する機会があったので、手順化しました。
chefを使ったjenkinsの構築方法です。

環境

centos6.5(vagrant)

chefのインストール

chefdkを使ってchefをインストールします。


# install chef dek
sudo rpm -ivh https://opscode-omnibus-packages.s3.amazonaws.com/el/6/x86_64/chefdk-0.3.5-1.x86_64.rpm

# temporary setting path
export PATH=/opt/chefdk/embedded/bin:$PATH

# knife install
chef gem install knife-solo

安定しているchef11系を利用します。

cookbookの用意


knife solo init chef-repo

knife soloでリポジトリを作成しています。knife zeroでも問題ありません。

Berkfileの記述


site :opscode
cookbook 'java'
cookbook 'jenkins'

javaはversion8を利用するので、jenkinsのopscodeとは別に導入します。

Berkfile実行


berks vendor cookbooks

Berksfile.lockが作成されます。私の環境では以下のようになりました。


DEPENDENCIES
  java
  jenkins

GRAPH
  apt (2.7.0)
  java (1.31.0)
  jenkins (2.3.1)
    apt (~> 2.0)
    runit (~> 1.5)
    yum (~> 3.0)
  packagecloud (0.0.18)
  runit (1.6.0)
    packagecloud (>= 0.0.0)
  yum (3.6.0)

role作成

jenkins用のroleを用意します。


{
  "name": "jenkins",
  "default_attributes": { },
  "override_attributes": {
    "java": {
      "install_flavor": "oracle",
        "jdk_version": "8",
        "java_home": "/usr/local/java",
        "oracle": {
            "accept_oracle_download_terms": "true"
          }
        }
    },
  "chef_type": "role",
  "json_class": "Chef::Role",
  "run_list" : [
    "recipe[java]",
    "recipe[jenkins::master]"
  ]
}

ファイル名はroles/jenkins.jsonにします。

enviroment作成

開発用のenviromentを用意します。jenkinsだからproductでいいのかもしれません。好みですかね。


{
  "name":"development",
  "chef_type": "environment",
  "json_class":"Chef::Environment",
  "description":"web server role",
  "default_attributes": {},
  "override_attributes": {}
}

node作成


{
  "environment": "development",
  "run_list": [
    "role[jenkins]"
  ],
  "automatic": {
    "ipaddress": "192.168.33.50"
  }
}

ipaddressは立ち上げているvagrantのipaddressです。

実行


knife solo cook 192.168.33.50

確認(java)


java -version
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)

確認(jenkins)


http://192.168.33.50:8080/

10分でjenkinsが動かせます。とはいえ、pluginは自力で入れないと画面に反映されないので、地道に導入していきましょう。

以上

*注意*chefのopscodeは自分用のrecipeを書くときにも非常に参考になります。
しかし、このjenkinsのopscodeはひどいコードなのでマネをしてはいけません。別の読みやすいコードを参考にしましょう

参考サイト

この記事がお役にたちましたらシェアをお願いします

serverspec nginxのテスト

公開日：2015年05月28日

いつも同じようなコードを書いているので、他のプロジェクトでも利用できるように代表的なテストコードを記載

環境

centos6.6
ruby 2.2.2p95

nginx_spec.rb

nginxのインストールは、rpmを利用して取得しています。


require 'spec_helper'

# ngix package　& version check
describe package('nginx') do
  it { should be_installed }
  it { should be_installed.with_version "1.8.0" }
end

# port check
describe port(80) do
  it { should be_listening }
end

# nginx service status
describe service('nginx') do
  it { should be_enabled }
  it { should be_running }
end

この記事は適宜更新していく予定です。

以上

参考サイト

serverspecでテストを書いた

この記事がお役にたちましたらシェアをお願いします

serverspec unicornのテスト

公開日：2015年05月28日

いつも同じようなコードを書いているので、他のプロジェクトでも利用できるように代表的なテストコードを記載

環境

centos6.6
ruby 2.2.2p95

unicorn_spec.rb

unicornのインストールは、gemを利用しています。


require 'spec_helper'

# port check
describe port(8081) do
  it { should be_listening }
end

# sock
describe file('/tmp/unicorn.sock') do
  it { should be_socket }
end

この記事は適宜更新していく予定です。

以上

参考サイト

serverspecでテストを書いた

この記事がお役にたちましたらシェアをお願いします

2015年5月27日水曜日

redmineの導入 redmineをunicornとnginxで動かす

公開日：2015年05月27日
最終更新日：2015年05月28日

以前の記事でredmineのインストール手順を記載しました。
今回はunicornとnginxを使ってredmineを動かす設定をします。

環境

centos6.6
redmine2.2.3(ruby1.9.3, rails3.2.12)
nginx1.8.0

注意

railsのアプリでunicornとnginxの連携をやったことがないと、理解できない可能性があります。
無理だと思ったら諦めて、インストーラーを使って動作させるのも選択の一つです。redmineは所詮ツールだということを忘れないようにしましょう。

unicornをインストール


// redmineのフォルダに移動
cd /var/www/rails/redmine

// Gemfileを開く
vi Gemfile

Gemfile

Gemfileにunicornを記載します。


gem "unicorn"

unicornをインストール


bundle install

unicornの導入に成功したかどうかを、仮起動で確かめます。


bundle exec unicorn_rails -l 8081 -E production

localhost:8081でredmineの画面が表示されることが確認できれば、導入は成功です。

設定ファイル

導入に成功したら、細かな設定をするためのconfigファイルを用意します。


// プロジェクトルートに移動
cd /var/www/rails/redmine
// unicorn.rbを作成
touch config/unicorn.rb

unicorn.rb

unicorn.rbには以下のように設定を記載します


@app_path = '/var/www/rails/redmine'

worker_processes 2
working_directory "#{@app_path}/"
preload_app true
timeout 30
listen "/tmp/unicorn.sock", :backlog => 64
listen 8081, :tcp_nopush => true
pid "/tmp/unicorn.pid"
stderr_path "#{@app_path}/log/unicorn.stderr.log"
stdout_path "#{@app_path}/log/unicorn.stdout.log"

before_fork do |server, worker|
  defined?(ActiveRecord::Base) and ActiveRecord::Base.connection.disconnect!
  old_pid = "#{server.config[:pid]}.oldbin"

  if old_pid != server.pid
    begin
      sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
      Process.kill(sig, File.read(old_pid).to_i)
    rescue Errno::ENOENT, Errno::ESRCH
    end
  end
  sleep 1
end

after_fork do |server, worker|
  defined?(ActiveRecord::Base) and ActiveRecord::Base.establish_connection
end

動作確認

作成したconfigファイルを指定して動かします。nginxとの連携を考慮し、バックグラウンドで動かします。


// プロジェクトルートに移動
cd /var/www/rails/redmine

// unicorn起動
bundle exec unicorn_rails -c config/unicorn.rb -E production -D

動作停止

バックグラウンドで動かしているので、コマンドで停止します。


cat /tmp/unicorn.pid | xargs kill

画面が非表示になればunicornでの起動と停止は成功です。

nginxとunicornの連携

さて次はnginxとunicornを連携する設定をおこないます。

/etc/nginx/nginx.conf


user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    # 以下を追記
    upstream unicorn-redmine {
        server unix:/tmp/unicorn.sock;
    }

    include /etc/nginx/conf.d/*.conf;
    
}

upstream unicorn-redmineの箇所を追加しています。unicornのソケット通信との連携を設定しています。

/etc/nginx/conf.d/default.conf


server {
    listen       80;
    client_max_body_size 1G;
    server_name  localhost;

    #charset koi8-r;
    #access_log  /var/log/nginx/log/host.access.log  main;

    location / {
        root /var/www/rails/redmine/public;
        try_files $uri/index.html $uri.html $uri @app;
    }
    
    location @app {
        proxy_redirect off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_connect_timeout 60;
        proxy_read_timeout 60;
        proxy_send_timeout 600;

        # If you don't find the filename in the static files
        # Then request it from the unicorn server
        if (!-f $request_filename) {
            proxy_pass http://unicorn-redmine;
            break;
        }
    }
    

    #error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ \.php$ {
    #    proxy_pass   http://127.0.0.1;
    #}

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

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #    deny  all;
    #}
}

nginxの設定は以上になります。

nginxの再起動とunicornの起動


// unicorn起動
bundle exec unicorn_rails -c config/unicorn.rb -E production -D

// nginx再起動

localhostでredmineのトップページが確認できれば成功です。ポートの8081を指定すると、unicornだけで動作しているのも確認できると思います。

以上

参考サイト

この記事がお役にたちましたらシェアをお願いします

日時

2015/05/24

タイムライン

14:30 王子駅到着
14:35 飛鳥山公園到着
15:35 飛鳥山公園下山

登山概要

今回は飛鳥山公園(あすかやまこうえん)へ行ってきました。

東京で一番低い山と言われていて、標高は25.3m(推測)です。しかし、国土地理院に申請は受理されていないので、公式には山と認められていません。
公園内には児童公園があるので子供が沢山いました。また、カップル、家族連れ、近場の大学生等、多くの人々を見かけました。

王子駅 - 飛鳥山公園

最寄り駅は『JR王子駅』です。王子駅の中央口から出てすぐの場所に飛鳥山公園はあります。
公園内には徒歩で入ってもいいのですが、せっかくなのでモノレールに乗ってみました。
モノレールは無料で、十人くらい乗ることができる大きさです。少し登山気分になれたかもしれません。

飛鳥山公園

とても綺麗に整備された公園だという印象を受けました。
都心の駅前の一等地に、これだけの大きさの公園を維持し続けているのは、区民に愛されている証拠でしょう。
ベンチに座って目を閉じていると、温かい陽気のせいもあり眠ってしまいそうになるくらい心地の良い場所でした。

飛鳥山公園-渋沢史料館-

今回私が来たのは、登山というよりこの『渋沢史料館』が目的でした。
日本資本主義の父と称される渋沢栄一氏の生涯と事績に関する博物館です。晩香廬（ばんこうろ）は重要文化財にも指定されています。

まとめ

都心でありながら木々に囲まれた静かな場所でした。
デートの途中でぶらっと立ち寄るのに適しているのではないでしょうか。

もちろん都内からのアクセスは抜群によく、王子駅周辺にもたくさん遊ぶ場所があります。

でわ

Instagramに登山写真をアップしました。

マウンテンチャンネルに詳細な登山情報をアップしました。

飛鳥山公園(あすかやまこうえん)

登山の関連記事

この記事がお役にたちましたらシェアをお願いします

2015年5月26日火曜日

Bower Errors: Exit Code # 128 & Failed connect

grunt bower:installコマンドでJavascriptライブラリをダウンロードしようとしたところ、上記のエラーが発生しました。

環境

windows7
bower 1.4.1

原因

ログを追うと、SSL certificate problem: self signed certificateとなっていたので、gitのセキュリティ証明書の問題とわかりました。

修正方法

.git/configに証明書をチェックしないように設定します。方法は以下の通りです。


git config --global http.sslVerify false

上記のコマンド実行後、grunt bower:installを再度実行すれば問題なく動作しました。

以上

参考サイト

この記事がお役にたちましたらシェアをお願いします

2015年5月24日日曜日

日時

2015/05/23

タイムライン

10:30 軍畑駅到着
10:50 高水三山登山口到着
11:30 高水三山山頂到着
11:50 岩岳石山山頂到着
12:30 惣岳山山頂到着
13:20 御岳駅到着

登山概要

今回は高水三山(たかみずさんざん)へ行ってきました。

高水三山(たかみずさんざん)とは、高水山（たかみずさん）、岩茸石山（いわたけいしやま）、惣岳山（そうがくさん）の3つの山の総称です。
都内からの交通アクセスが抜群に良いので、休日は多くの人が訪れる山峰です。

軍畑(いくさばたけ)駅

下車したのは『軍畑(いくさばたけ)駅』。新宿から2時間程度で到着できます。
この日は朝寝坊しての出発でした。なので、駅に到着したのは10:30。前日の終電まで残業のダメージがあったのか、朝早くに起きられませんでした。

でも、今回はちゃんと地図を持参しました。

軍畑(いくさばたけ)駅 - 高水三山

軍畑(いくさばたけ)駅 - 高源寺 - 高水三山と歩みを進めていきます。
この日は天気もよく絶好の登山日和でした。
よく整備された山道で足場もよく、さくさくと先に進むことができる道です。

下記は高水山常福院（たかみずさんじょうふくいん）です。

岩茸石山（いわたけいしやま）

三つの山の最高峰です。標高793メートルです。この日は混雑していて、食事をする場所がありませんでした。
といっても寝坊したせいで昼食はおろか、食べものを何も持参しなかったんですけどね。

惣岳山（そうがくさん）

岩茸石山（いわたけいしやま）から30分ほどの位置にある山。最後の関門の急な岩場では注意が必要です。登山というより軽いクライミングです。軍手や手袋を装着しましょう。

御岳駅

惣岳山（そうがくさん）から御岳（みたけ）駅までは一時間程の距離でした。
距離は長いですが、危ない道や体力が奪われるような勾配はほとんどありません。
疲れはピークでしょうが、がんばりどころです。

玉川屋

名店『玉川屋』。帰宅の電車がくるまで時間があったので、ここで昼食を取りました。
Tokyo x 肉南そば 1,080円也。
疲れた体にも優しい味でした。とても美味しかったです。

まとめ

今回は登山バックも持っていかず、日常の鞄と私服での登山でしたが、全然問題ありませんでした。

登山初心者でも楽しめる山です。都内からのアクセスもよく、健脚なら3時間で往復できます。
運動不足の人にも薦められる山です。また来たいと思いました。

でわ

PS: 方位磁石買うの忘れましたー。

Instagramに登山写真をアップしました。

マウンテンチャンネルに詳細な登山情報をアップしました。

高水三山(たかみずさんざん)

山に関する関連記事

この記事がお役にたちましたらシェアをお願いします

2015年5月23日土曜日

redmineの導入 redmineの導入とバージョンアップを行う

redmineのインストール手順の記載。
以下の手順で実装

既存のredmineを異なるサーバーに移行
移行したredmineを最新バージョンにアップデート

今回の説明では珍しくchefは使いません。chef版はまた今後記載します。

環境

centos6.6

gitをインストール

git cloneが必要なのでgitをインストールします。


yum -y install git

rbenvをインストール

rbenvはrubyのバージョンを管理するツールです。

今回はrubyのバージョンを管理したいのでrbenvをインストールします。


// rbenvを取得
git clone https://github.com/sstephenson/rbenv.git ~/.rbenv

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

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

// 設定の再読み込み
$ exec $SHELL -l

// rbenvの確認
rbenv --version
rbenv 0.4.0-148-g5b9e4f0

ruby-buildをインストール

読んで時の如く、rubyのbuildに必要なライブラリです。


git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

パッケージをインストール

rubyのビルドに必要なパッケージをインストールします


yum -y install openssl-devel
yum -y install gcc

rubyをインストール

rubyの1.9.3と2.2.2をインストールします


rbenv install 1.9.3-p551
rbenv install 2.2.2

rbenv versions
  1.9.3-p551
  2.2.2

デフォルトのruby設定

デフォルトのrubyを1.9.3に指定します


rbenv global 1.9.3-p551

ruby -v
ruby 1.9.3p551 (2014-11-13 revision 48407) [x86_64-linux]

bundlerの導入

Gemパッケージの管理をできるようにします。


gem install bundler

rehash

rbenvを再読み込みします


rbenv rehash

redmineのinstall準備


// 必要なパッケージ(postgrres) gemfileのコメントアウトでも良い
yum -y install postgresql-devel

// sqlite3 gemfileのコメントアウトでも良い
yum -y install sqlite sqlite-devel

// rmagic gemfileのコメントアウトでも良い
yum -y install ImageMagick ImageMagick-devel

無駄にパッケージを入れるより、Gemfileをコメントアウトするほうをおすすめします。railsでの開発経験がない人は、パッケージをいれておきましょう。

redmineソースを取得


// フォルダを作成
mkdir -p /var/www/app

// フォルダに移動
cd /var/www/app

// バージョンを指定して取得
svn checkout http://svn.redmine.org/redmine/tags/2.2.3/ redmine2.2.3

cd redmine2.2.3

ここでは最新版でなく、古いredmineをダウンロードします。redmineのバージョンごとの取得方法はここで記載しています。

DBの作成

DBはmysqlがインストール済みの前提で進めます。


mysql -uroot -p

create database redmine character set utf8;
create user 'redmine'@'localhost' identified by 'password';
grant all privileges on redmine.* to 'redmine'@'localhost';

DB設定ファイル変更

上記で作成したDBに接続するための設定ファイルを作成します。


// コピー
cp database.yml.example database.yml

// 上記で設定したデータに変更
production:
  adapter: mysql2
  database: redmine
  host: localhost
  username: redmine
  password: password
  encoding: utf8

mysqlのバージョンが5.1以降の場合は、adapter: mysqlをadapter: mysql2に変更する必要があります。

セッションの生成


cd redmine2.2.3

bundle exec rake generate_secret_token

テーブル作成


RAILS_ENV=production bundle exec rake db:migrate

デフォルトデータをデータベースに登録


RAILS_ENV=production  bundle exec rake redmine:load_default_data

起動テスト


ruby script/rails server webrick -e production

ブラウザアクセステスト


http://localhost:3000/

画面が表示されればOK。

以上

参考サイト

Redmineのインストール

この記事がお役にたちましたらシェアをお願いします

2015年5月22日金曜日

US-ASCII (Encoding::InvalidByteSequenceError)

公開日：2015年5月22日

環境

vagrant(centos6.5)

概要

chefを使って新しく環境構築をしようとしていたら

/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/json-1.8.2/lib/json/common.rb:155:in `encode': "\xE2" on US-ASCII (Encoding::InvalidByteSequenceError)

というエラーが発生しました。

原因は、表示されているようにjsonパース時のエンコーディングの問題です。

エラーの発生する条件

chefのインストールには、ChefDK0.6を利用しました。
このパッケージでrubyの環境を導入すると、上記のエラーが発生する『バグのあるruby』がインストールされてしまいます

エラーの発生したコマンド


berks vendor cookbooks

/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/json-1.8.2/lib/json/common.rb:155:in `encode': "\xE2" on US-ASCII (Encoding::InvalidByteSequenceError)

Berkshelf3を使ってcookbookをインストールするときに発生しました。

修正方法


export LANG=en_US.UTF-8
berks vendor cookbooks

上記のように、コマンド実行前にエンコーディングを指定すれば正常に動きます。

以上

参照

Encoding Errors

この記事がお役にたちましたらシェアをお願いします

2015年5月21日木曜日

redmineの導入バージョンを指定してredmineのソースを取得する

redmineのインストールのまとめ。
色々な人が参照できるように、今回はchefは使いません。

環境

centos6.6

svnをインストール

ソースコードの取得にはSubversionが必要なので、ない場合はsvnをインストールします。


yum -y install subversion

redmineをインストール

redmineのバージョンを複数管理したいので、複数取得します。

version2.2.3を取得する


svn checkout http://svn.redmine.org/redmine/tags/2.2.3/ redmine2.2.3

version3.0.3を取得する


svn checkout http://svn.redmine.org/redmine/tags/3.0.3/ redmine3.0.3

上記のようにsvnを利用してリポジトリからソースコードを取得してやれば大丈夫です。

以上

参考サイト

Redmineのインストール

この記事がお役にたちましたらシェアをお願いします

2015年5月18日月曜日

世界のドローンビジネスの調査その5 医療分野のドローン　そして未来へ

前回はアマゾン・プライム・エアについて紹介しました。
今回は医療分野のドローンを調査し、最後に未来のドローンについて考えたいと思います。

マイクロスコピック・ドローン

マイクロスコピック・ドローンと呼ばれるドローンは、ナノマシーンです。
このドローンはナノマシーンが体内を駆け巡って、動脈の悪いところを治してくれます。
プラスチックに近い物質でできており、そのサイズは人間の毛髪の1000分の1程度。

治療箇所へナノ粒子をたどり着かせ、炎症治療のための薬を放出するらしいです。
凄い時代ですね。

商用への変換

現在のドローンは一部の熱狂的なユーザーが遊びで利用しているのが現状です。
ここから徐々にビジネスで利用できるように変化していくことが必要なってきます。

別にビジネスにする必要はないんじゃないかという声も聞こえてきそうですが、ビジネスにすることで加速度的にテクノロジーは進歩します。資金がないと研究も進まないので、利益を出すことは重要です。

現在は空撮の市場くらいしかありませんが、医療、農業、配送、飲食、レースと様々な分野でドローンは使われていくはずです。

人の仕事は無くならない

テクノロジーの発展により、人の仕事が失われるのではないかという懸念をいだいている人は多いようです。
確かにパソコンが多くの職業のあり方を変えたように、ドローンも多くの職業のあり方を変えるでしょう。

でも、パソコンが多くの新しい市場を生み出したように、ドローンも新しい市場を生み出すはずです。
こうやって時代と共に少しづつ人間の生活は豊かになっていくのだと思います。

そして未来へ

今、ドローンに期待されているのは、どうしても人間がやらなければいけない危険な仕事をドローンが担ってくれるのではないかということです。
でも、それ以上の役割を果たしてくれることになると思います。

遠くない未来。僕らの頭上を当たり前にドローンが飛び、より便利な世界ができていることを期待し、『世界のドローンビジネスの調査』のシリーズを終了したいと思います。

以上。最後までつきあってくれたかた、本当にありがとうございました。

追伸: これからもドローンの情報は追いかけていきますよ。終わりじゃないですよ!

参考

世界のドローンビジネスの調査シリーズ(2015/05/12 - 2015/05/18)

この記事がお役にたちましたらシェアをお願いします

2015年5月17日日曜日

登山日時

2015/05/17

タイムライン

8:30 飯能駅到着
9:20 さわらびの湯バス停到着
9:30 棒ノ折山河又登山口到着
11:10 棒ノ折山山頂到着
12:30 さわらびの湯到着
13:10 飯能駅到着

登山概要

今回は棒ノ折山(棒ノ折嶺)へ行ってきました。

標高969mと低山ですが、眺望のよい山でした。この日は天気に恵まれ、素晴らしい景色を楽しめました。

飯能駅 - さわらびの湯バス停

駅はおなじみの『飯能駅』。池袋から特急で1時間程度で到着できます。
駅からはバスに乗って『さわらびの湯バス停』まで向かいます。ここでもアニメヤマノススメを見かけました。
最近行くところ行くところでよく見かけます。今度アニメを見てみようかななんて思ってしまいました。

さわらびの湯バス停 - 棒ノ折山河又登山口

50分ほど満員のバスに揺られてさわらびの湯に到着。9:30頃だったので、すでに人で溢れていました。
ここで先週購入した地図を忘れたことに気づきました。

*棒ノ折山(棒ノ折嶺)が掲載されているのは『奥多摩』です。

時間も時間だし、道に迷うのも嫌なので、白谷橋経由でなくすぐ近くの河又登山口へ向かいました。

棒ノ折登山

河又登山の山道はいきなり急な斜面が続きます。そして、しばらく何もありません。やはり白谷橋経由で登るべきだったとちょっと後悔しました。

棒ノ折頂上

頂上までは約1時間30分ほどで到着できました。良い天気ということもあり、人で溢れていました。

景色も素晴らしかったです。

ただ、人が多いのでドローンでの撮影は断念しました。子供も沢山いました。

さわらびの湯バス停 - 飯能駅

下山は同じ登山道を通って下山しました。1時間くらいでした。
バス停の時刻表を見ると、15分くらいでバスの時間だったので、慌てて名栗まんじゅうを購入して食べながら待ちました。

まとめ

低山ながら景色の良い山でした。でも、次は河又からでなく、白谷橋から登ろうと思います。
高水三山からも来れる距離らしいので、そのうち挑戦してみたいです。

登山初心者でも楽しめる山だと思います。都内からのアクセスもよく、健脚なら3時間で往復できます。
運動不足の人にも薦められる山です。また来たいと思いました。

でわ

PS: 次こそは地図をもっていきます!!。あとは方位磁石も。

Instagramに登山写真をアップしました。

マウンテンチャンネルに詳細な登山情報をアップしました。

棒ノ折山

山に関する関連記事

この記事がお役にたちましたらシェアをお願いします

2015年5月16日土曜日

世界のドローンビジネスの調査その4 アメリカの巨人アマゾンのアマゾン・プライム・エア

前回はカナダのドローンの法を紹介しました。
今回は世界で一番有名なドローンの実用ビジネス実験、アマゾンのアマゾン・プライム・エアについて調査したいと思います。

アマゾン・プライム・エア

アマゾン・プライム・エアは無人航空機を使って、アマゾンの出荷する商品を消費者へ直接届けてくれるというものです。
つまり、空の宅配サービスです。アマゾンのこのシステム構築が上手くいけば、ピザの宅配サービス等、様々な宅配サービスでドローンが商用利用されることになるでしょう。

動画 :アマゾン・プライム・エア

上記の動画を見ていただけばわかると思いますが、数年前はSFのワンシーンだったことを現実にしようとしているのです。
とはいえ、現実には技術的、法律的、倫理的にも問題が山積みです。

FAA（米国航空局）の規定

2014年6月にFAA（米国航空局）が規定したドローン（無人航空機）の法律は、商業配達を禁止するものでした。この結果、ドローンによる無人配達を行うというアマゾンの計画は一時的に夢物語となってしまいました。アマゾンは規定があまりにも厳しすぎるとFAA（米国航空局）に文句を言いました。

そして、2015年3月。FAA（米国航空局）はAmazonに「実験的耐空証明書」を発行し、同社が「Amazon Prime Air」配送ドローンの研究開発や操縦訓練を実施することを認めました。
しかし、アマゾンはこの判断に対しても、あまりにも結論を出すのが遅すぎる。意味が無い。と非難しました。
ビジネスはスピードが命なので、アマゾンが怒るのは当然です。CEOジェフ・ベゾスの怒りの顔が浮かぶようです。

*ジェフ・ベゾスの性格を知りたいひとは以下の本がオススメです。

アメリカからカナダへ

FAA（米国航空局）の動きにしびれをきらしたアマゾンは、カナダで実証実験を開始しました。今はカナダ政府の全面援助を受けなら、ブリティッシュ・コロンビア州で複数のプロジェクトを進めているそうです。

カナダには多くの専門家が集まっていて、アマゾン・プライム・エアに向けて様々な角度からテストを行っているようです。

宅配サービス以外の目的

では、なぜアマゾンはここまでドローンを利用した宅配に力を入れるのでしょうか。それは、宅配サービスの実現だけが目的でないからだと思います。一般の人が想像するアマゾンという会社は、ネット通販の会社だと考えているでしょうが、それは違います。

アマゾンはインターネットの世界では、AWSと呼ばれるクラウドっサービスも提供しており、技術力をもつインフラの会社でもあるのです。しかも、その技術力とインフラは安価かつ強力で、クラウドインフラのほぼデファクトです。

そうです。アマゾンはAWSの成功で理解しているのです。自分たちのドローン宅配サービスが成功すれば、AWSのように市場を独占できることを。それに加え、利用者にも多大なメリットが生まれます。さらには、ドローンの進化も加速し、ドローンの市場も大きくなります。だから、偏狭的までにドローンの開発に力を注いでいるのです。

日本でのアマゾン・プライム・エアの適用を考える

これはなかなか厳しいと思います。しかし、日本はいつも黒船によってしぶしぶ市場を開放してきました。
欧米でドローン宅配サービスが広まれば、日本でも自然に受け入れられていき、当然楽天などのECサービスを提供する会社も無人航空機サービスに参入してくるでしょう。そうなれば、空の法の整備は急速に進んでいくはずです。

アマゾン・プライム・エアの成功の可否が、空のビジネスの今後を占うのは間違いありません。
ですが、アマゾン・プライム・エアの話はひとまずここまでにしましょう。

次は空以外でのドローンのイノベーションの可能性を見てみたいと思います。

この記事がお役にたちましたらシェアをお願いします

2015年5月14日木曜日

世界のドローンビジネスの調査その3 カナダのドローンに関する法律

前回はカナダのADEを運ぶドローンの活用方法を紹介しました。
今回は、世界で一番ドローンの法整備が進んでいるカナダの法を以下に紹介します。

発行:カナダ交通局

安全案内

ドローンの操縦者はドローンを安全、かつ法規的に飛ばす責任を負っている。カナダでは、ドローンの操縦者は以下の決まりに従う必要がある。

カナダ航空規則に規定されたルールに従うこと
この法律は、私有地への侵入に関連する全ての都市、地方、準州の法律と同じように適用する

カナダ交通局は、以下の「操縦時にやること」「操縦時にやってはいけないこと」をドローン操縦者に期待している。

操縦時にやること

日の出ている間、天気の良い間にドローンを飛ばす。(曇りや霧のある日に使わない)
カメラ、モニター、スマートフォンを通してでなく、常に視界に捉えられる範囲で操縦する。
離陸する前に安全を確認する。自分に自問しよう。バッテリーは満タンか、飛行するには寒すぎないか。等。
飛行するための許可、特別な飛行操作許可の申し込みが必要なのかどうかを知ること。
他人のプライバシーを尊重すること。具体的には、私有地の上を飛ぶことを避ける。または許可なしに写真やビデオの撮影をしてはいけない。

操縦時にやってはいけないこと

空港、ヘリポート、飛行場から9キロ以内に近づいてはいけない。
地上から90メール以上の上空を超えてはいけない。
人、動物、建物、構造物、乗り物から150メートル以内に近づいてはいけない。
人気のあるエリア、大勢の人々の付近、スポーツイベント、コンサート、フェスティバル、花火大会で飛ばしてはいけない。
動いている乗り物の近く、高速、橋、人通りの多い道、あなたが危険だと思ったり、運転者の気が散るだろう場所を避ける。
制限空域内、米軍基地、刑務所、山火事の上空や近くでは飛ばしてはいけない。
最初に反応した人を妨害する可能性のあるいずれの場所でも飛ばしてはいけない。

画像 : カナダ交通局PDF

許可と安全の要件

無人飛行機を法律的に飛行させるためには、免責の中に要約された厳しい安全条件に従う必要があります。もしくはカナダ交通局に許可を申し出る必要があるかもしれません。その条件は、どのように、どこで自分の飛行機を利用するか次第であるのと同じで、重量、飛行機の種類次第である。

飛行機の条件

重量35kg以上なら、飛行機を使う前に、飛行操縦許可証を申し込む必要があります。
重量35kg未満で、レクリエーションの目的に使用するなら、許可の必要はありません。

重量25kg未満の無人飛行機は、規則の免責の資格を満たすので、許可なしで飛ばすことが許されています。

飛行機の条件

重量が2kg以下、もしくはカナダ交通局のUAVは2kg以下という安全基準を満たすことができるなら、飛行許可は必要ありません。
重量が2.1kgから25kgの間で、かつカナダ交通局の『UAVは重量が2.1kgから25kg』という安全基準を満たすことができるなら、飛行許可は必要ありません。しかし、フォームに入力してカナダ交通局に機体の存在を知らせなければいけません。

人気がある(売れている)ドローンは？

カナダの法はさすがにうまく纏まっていると思います。
ちなみに世界で一番人気がある(売れている)ドローンは『DJI PHANTOM 3』で、機体の重量は1kg程度です。
高い飛行能力と高性能のカメラが備わっています。

操縦テクニックが中級〜上級になったと自負できるならオススメの機体です。購入してみてはどうでしょう。

日本でのカナダの法の適用を考える

カナダのドローンの法は日本でも適用できる部分が多そうです。
特徴的なのは法律で強制的に縛るのではなく、お願いに近いのが特徴ですかね。
『人の迷惑にならない範囲で操作してください』という当たり前のルールを、安全案内という形で明文化した感じがします。

あれもダメ、これもダメでは何も生まれなくなってしまいます。
いつだって時代を変える大きなイノベーションは、新しいテクノロジーが生み出します。
ただ、恐怖を感じる人が多いのも事実なので、バランスよく法を組み立てる必要があります。

さて、カナダのドローンの法は理解できました。
次はイノベーション大国アメリカのAmazon Prime Airのビジネスモデルを見てみようと思います。

参考サイト

この記事がお役にたちましたらシェアをお願いします

世界のドローンビジネスの調査その2 カナダのAED運搬

前回はシンガポールのレストランでのドローンの活用方法を紹介しました。
今回は世界で一番ドローンの実用や法整備が進んでると言われているカナダでのドローンのサービスを調査しましょう。

カナダのAED運搬

みなさんはAEDをご存知でしょうか。AEDとは、突然心臓が正常に拍動できなくなった心停止状態の心臓に対して、電気ショックを行い、心臓を正常なリズムに戻すための医療機器のことです。

カナダでは、ドローンを使ってAEDを運ぶテスト飛行が行われています。テスト飛行の内容は以下の通りです。

心肺停止で人が倒れた際に携帯電話で通報
通報先はGPSを使い現場への最短距離を検出
通報から1分後にドローンが出動
- 最高速度は時速80キロ
- 林の上や水上も移動できるためアクセスしにくい場所にも素早く到着できる
到着するとAEDの音声ガイダンスにしたがって周囲の人が対応

実験の結果は、救急隊より5～6分も早かったそうです。多くの人の命を救える素晴らしい実験結果です。
心停止からの経過時間は1秒たりとも無駄にできないので、これは素晴らしいテクノロジーの応用例ですね。

日本のAED運搬での実現性を考える

動画 :TU Delft - Ambulance Drone(救急ドローン)

日本でのAEDの国内の設置台数は既に40万台を超えたとされています。なのでこの事例は日本でも適応できそうです。人命もかかっていますし、人命を重んじる日本でも問題なく受け入れられるでしょう。
ただ、残念なのは、日本の一般人のAEDを活用した事例が少ないことです。普及台数ではなく、使用者である市民のAED啓発に多くの課題が残っているのが現状です。
ドローンの技術的な側面よりも、日本人のAEDに関するリテラシーが普及の鍵になりそうです。

カナダのドローンの法整備

他の記事や今回の冒頭でも記載したように、カナダはドローンの法整備が進んでいると言われています。
学ぶことはまねぶこと。きっとカナダのドローンに関する法は、日本で法律をつくっていくうえで役に立つはずです。

ではカナダのドローンの法とはどのようなものでしょうか。
次は、カナダはドローンの法を調べてみましょう。

参考

この記事がお役にたちましたらシェアをお願いします

2015年5月12日火曜日

世界のドローンビジネスの調査その1 シンガポールのレストラン

日本でのドローンの話題は、官邸や善光寺での度の過ぎたイタズラが中心ですが、世界ではビジネスでドローンを利用していこうと様々な試みがおこなわれています。

僕がドローンを購入してから一ヶ月が経ちました。
もともとテクノロジーが好きなこともあり、ほぼ毎日ドローンを操作して遊んでいます。

このテクノロジーは日本でも積極的に取り入れていくべきだと思います。
現在の私達の生活がインターネットに多大な恩恵を受けているように、ドローンもインターネットと同じくらい大きな可能性を秘めていると思います。

といってもアイディアを無から生みだすのは現実的ではありません。
なので、世界で試されているドローンを使ったビジネスを調査していきましょう。

シンガポールのレストラン

わずか半世紀で世界有数の豊かな国になったシンガポール。このシンガポールのレストランでは、ドローンをウェイターとして利用するサービスを試しはじめました。

画像 :gigazine.net

経済発展を続けるシンガポールでは、多くの飲食店が人手不足に悩まされています。理由は様々ですが、低賃金なため働きたくない(働いても生活が苦しい)ということが大きな原因にあるようです。(日本でもパートやバイトといった低賃金のスタッフをメインに据えて運営することでなんとか利益を出しています)

そこで考えられたのが

「flying robot waiters」

つまり、ドローンのウェイターサービスです。プログラミングでコントロールされたドローンを使ってサービスを提供しています。

このサービスを提案したウォン社長は、ロンドンの大学と、アメリカのスタンフォードでエンジニアリングを学んだ後、シンガポール海軍での経験を経てこのレストランを開きました。
ずいぶんと技術思考よりのビジネスだ思いましたが納得です。

ドローンの請け負う仕事範囲

実際のレストラン内でドローンが料理やドリンクを運ぶのは、調理場からホールまでの間だけだそうです。
実際に顧客の目の前まで料理を運ぶのはまだウェイターの仕事です。

確かにドローンがお客さんの目の前で止まって料理を机に置いて戻っていくというのは、お客さん側の心理的なハードルが高いかもしれませんね。レストランは雰囲気も大事ですから。

日本のレストランでの実現性を考える

日本でのこのサービスの導入を考えてみたいと思います。
まず既存の高級レストランやお店ではNGです。情緒を重んじる日本人には確実に不評でしょう。炎上確定です。

やはり、吉野家や松屋みたいな早い、安い、(そこそこ)うまいといったような店が対象になるでしょう。

とはいえ、ビジネスの視点で考えると、低賃金のアルバイトのコストと、発展途上のドローンのシステム開発のコストが釣り合うわけありません。
なので既存のビジネスでなく、新規ベンチャーとしてビジネスを立ち上げ、VC(venture capital)の力を借りてレストラン業界のパラダイムシフトを起こす必要があります。

ビジネス視点だと、時給700円のバイトビジネスに勝つ可能性はゼロです。なので、他の視点のからマネタイズしていく必要があります。
ただ、それで成功してもレストラン産業のビジネスといえるかは微妙ですね。

まとめ

現状では日本のレストランでドローンの適用は厳しそうです。ただ、とんでもなく広いフロアのお店なら数の論理でうまくいくかもしれません。ただ相当の集客力と高度なドローンのシステム構築が要求されるので、こういうビジネスはアメリカから生まれそうな気がします。日本では厳しそうです。

さて次回はドローンの法整備が最も進んだ国、カナダの実例を研究したいと思います。

この記事がお役にたちましたらシェアをお願いします

2015年5月11日月曜日

技術的負債の返却その2 rubyのバージョンアップ

公開日：2015年5月11日
最終更新日：2015年5月17日

技術的負債の返却は計画的に(by ◯コム)。

以前に、railsを4.1.2から4.2.1にバージョンアップしたので、今回はrubyのバージョンをruby 2.1.2 からruby 2.2.2にupdateします。
以下、忘備録です。

環境

rails4.2.1
vagrant(centos6.5)
chef11.18.0.rc.1

vagrantを立ちあげて、rubyの現在のバージョンを確認する


vagrant up
vagrant ssh

ruby -v
ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-linux]

chefのrolesで設定しているjsonファイルを更新する

Before


    // something...

    "rbenv": {
      "rubies": "2.1.2"
      "global" : "2.1.2",
      "gems" : {
        "2.1.2" : [
          { "name" : "bundler" }
        ]
      }      
    },

    // something...

After


    // something...

    "ruby_build": {
      "upgrade": "sync"
    },
    "rbenv": {
      "rubies": "2.2.2",
      "global" : "2.2.2",
      "gems" : {
        "2.2.2" : [
          { "name" : "bundler" }
        ]
      }      
    },

    // something...

変更のポイントは以下の箇所になります。


    "ruby_build": {
      "upgrade": "sync"
    },

上記の設定は、chef-ruby_buildを利用している場合、既にruby-buildがインストールされていると更新がかからないようになっているので、 ruby_buildのattributeにupgradeを設定しています。上記以外に、"upgrade": trueでも動作するみたいです。

chefを実行


cd {chefのフォルダ}
knife solo cook 192.XXX.33.XXX

結果


ruby -v
ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]

無事に変更されています。bundleのgemも変更されているのでbundle installを実行する必要があります。


bundle install --path /tmp

vagratでbundle installをするときは、ホストとsyncしていないフォルダを指定します。syncしているフォルダを選択すると、bundle execが途中で止まってしまいます(もしくは激重)。

デグレのチェックのためにテストコードを実行


cd {プロジェクトフォルダ}
bundle exec rspec spec

みんな大好きrspec。上記の処理を実行してエラーが発生しなければ問題ありません。

開発環境でdeploy

まずは念のために開発環境をdeployしてみましょう。deployツールにはcapistrano(3.2.1)を使用します。
最初に、rubyのバージョンを2.1.2に設定していたdeploy.rbとCapfileを2.2.2に変更します。

deploy.rbを修正


set :rbenv_type, :system # :system or :user
set :rbenv_ruby, '2.2.2'

Capfileを修正


require 'capistrano/rbenv'
set :rbenv_ruby, '2.2.2'

deploy実行

上記のファイルを変更したら、deployを実行します。


bundle exec cap development deploy

bundle installされるので時間がかかりますが、うまく動きます。

本番環境では「chefを実行」からの手順を開発環境と同じように実施すればOKです。

以上

参照

この記事がお役にたちましたらシェアをお願いします

実戦で学んだ現代登山の所持品について

公開日：2015年05月11日
最終更新日：2015年06月21日

こんにちわ。すっかり山ごもりエンジニアになっているエディです。
ゴールデンウィーク中だけでも、週4回登山に行くほど夢中になっています。

元々仲間と一緒には登山によく行っていたのですが、最近は一人でも登山に頻繁に行くようになりました。

なぜこんなにも登山にはまっているのか、自分でも理由はよくわかりません。僕は生まれも育ちも東京で、根っからのエンジニア体質。限りなくギークに近いです。体型も細いです。(いい大人なのに170cmで52-53kgくらい)
…このブログを読んだことがある方ならわかってるでしょうけど。

では、なぜ山に登るのか。

それは、山頂に到着した時の心地良い達成感なのかなと思っていましたが、どうも違うようです。僕が山に登る理由は、WEBやスマホ開発、楽器の練習や作曲、ドローンの練習等と同じ。言葉ではうまく説明しにくいのですが、『性にあっている』とでもいうのでしょうか。

登山道具以外のアイテム

どうでも良い前置きが長くなりました。
なにはともあれ、登山は誰でも気軽に楽しむことのできる趣味です。
しかし、持ち物や準備次第で、体への負担や危険度が大きく変わります。

一人で登山をこなすうちに、それは登山靴、ザック、雨具以外の持ち物、つまり登山用具でないものをどのように使い、利用しているかというのが意外と重要なのだなということに気が付きました。

というわけで今回は、登山用具以外で登山を楽にしてくれるアイテムを紹介したいと思います。

地図(本)

意外と所持していない人が多いのが地図です。
「これまで登山で地図なんか使ったことない」とか「地図ならスマートフォンで十分じゃない？」と思っている人は多いです。
私も最初の頃はそうでした。

しかし、ある規模以上の登山をするなら(5時間を超える登山)、地図はもっていくべきです。
確かに人気のある山には標識が数多くあります。迷うケースは少ないでしょう。
しかし、万が一方向を間違えてしまうと、簡単に迷いこんでしまうのも山の特徴です。

遭難したくて遭難する人は誰もいません。それでも、遭難する人が出てしまうのが山の怖さです。

なので、パーティー登山でも一人は地図を携帯するようにしたほうが良いです。一人なら絶対に持っていくべきです。特に初登山の山に一人に行く場合は絶対に忘れないようにしましょう。

オススメの地図は『山と高原地図』の地図です。

地図を持っていなくとも一度くらいは周りや本屋で目にしたことはあるでしょう。私も登山時はこの地図を持参していきます。

値段は1,000円ですが、たまにしか登山をしない人にはちょっと高いかもしれません。
しかし、安全が1,000円で手に入ると考えれば格安です。
是非手に入れて欲しいアイテムです。

スマートフォン

登山にスマートフォンは必須アイテムです。特にLineやfacebook等の友人と繋がっているSNSのアプリは必ず入れておきたいところです。万が一の時、家族や友人と連絡がとれる利点は大きいです。場所やキャリアによってはつながりにくいこともあるのですが、辺境の場所でも結構つながります。日本のインフラって凄いですよ。本当に。

よければ、僕が作成しているマウンテンチャンネルも是非利用してみてください。山では情報が命です。

また、スマホで位置情報とネットを使いつつ写真撮影をするとバッテリー消費が激しいので、換えのバッテリーも用意しておきましょう。もしくは、バックパック（ザック）に取り付けられるモバイルソーラーパネルでもいいと思います。

Suica（スイカ）, PASMO（パスモ）

Suica（スイカ）, PASMO（パスモ）などの交通系ICカードは、公共の乗り物を利用して登山にいく場合は必ず持っていきたいアイテムです。Suica（スイカ）, PASMO（パスモ）を使ったほうが切符より安いですし、便利です。

祝日や休日などに登山の行楽地に行く場合の電車やバスなどは、混雑していたり接続アクセスが悪いことも多いです(一本逃すと次は一時間後とか)。Suica（スイカ）, PASMO（パスモ）を使えば、財布から小銭を取り出す手間や両替のロスを最小限にすることができます。

また、現金よりも支払いにかかる時間が短く。周りのお客さんにも迷惑がかかりません。
なので、マナーという点からもSuica（スイカ）, PASMO（パスモ）は是非とも用意しておきたいです。
財布とは別にカードケースを用意して入れておくと100点です。

クレジットカード

これも理由はSuica（スイカ）, PASMO（パスモ）と同じです。登山は荷物も多いので、かさばる現金払いは極力避けたほうが無難です。
クレジットカードなら財布と違い邪魔にならないし、おみやげの購入でも残額を気にする必要がありません。
今は誰でも簡単にクレジットカードがもてる時代です。現金払い派の人ももっておきましょう。ポイントもたまります。

ドローン

スマホに次ぐ次世代の文明の利器ドローン。登山に行けば、大抵の人は写真撮影をすると思います。ドローンがあれば色々な角度から撮影することが可能です。
とはいえ、ドローンを自由自在に操るにはそれなりの練習が必要です。十分な技術をみにつけてから利用するようにしましょう。人混みで使うのもさけてください。サイズの小さいドローンがオススメですが、小さいドローンは操作がかなり難しいので練習あるのみです。

以上で『実戦で学んだ現代登山の所持品について』のまとめは終了です。この内容はまとめて、マウンテンチャンネルの特集にも追加しておこうと思います。

以上です。

Instagramに登山写真をアップしました。

マウンテンチャンネルに詳細な登山情報をアップしています。

山に関する関連記事

この記事がお役にたちましたらシェアをお願いします

2015年5月10日日曜日

三つ峠へ行ってきました。

公開日：2015年05月10日
最終更新日：2015年06月14日

登山日時

2015/05/09

登山概要

最近は登山にがっつりはまっています。今回は三つ峠へ行ってきました。

富士急行線で三つ峠駅というそのままの名称の駅があるので、そこで下車します。
富士急行線は2015年の3月(2ヶ月前ですね)からSuicaが使えるようになったらしく、切符の購入に手間取ることがなかったのでとても便利でした。

駅前はなにもありません。ちょっと離れたところにローソンがありました。

三つ峠登山口まで

三つ峠登山口までは、三つ峠駅からひたすら歩くことになります。
健脚の人で一時間くらいはかかると思います。
神鈴(しんれい)の滝遊歩道は素晴らしい場所なので寄り道することをオススメします。

三つ峠

三つ峠は初めての登山だったのですが、素晴らしい山です。今後は筑波山、富士山と同じく、毎年登山に行こうと思わせてくれました。
この日は天気が悪く、人は少なめで、山頂からの景色があまり良くなかったのが残念でしたが、それでも素晴らしい山ということはわかりました。

ロッククライミングはとても面白そうなのですが、はまったら怖いので一歩を踏みだせません。

天上山(カチカチ山)

帰りはカチカチ山の舞台となった天上山のロープウェイを使おうとおもったのですが、道に迷って到着することはできませんでした。標識どおりに進んだんだけどなあ。
地図を持っていかなかったので、仕方なく来た道を引き返しました。残念。

まとめ

また来たいと強く思える山でした。次回は天上山経由で来たいと思います。
都内から日帰りだと結構ギリギリの距離です。脚力に自信のない人は、一泊したほうがよいかもしれません。

でわ

PS 1 : 三つ峠に行く場合は地図をもっていったほうが良いです。Google mapでなく、登山用の地図です。

Instagramに登山写真をアップしました。

マウンテンチャンネルに詳細な登山情報をアップしました。

三つ峠(みつとうげ)

山に関する関連記事

この記事がお役にたちましたらシェアをお願いします

2015年5月8日金曜日

ドローンの試験場が茨城・つくばで開設 - ドローンの練習方法を考える-

ドローンの試験場が茨城・つくばで開設されることが決定されたそうです。
つくばといえば、僕の中では毎年登山に行っている筑波山のイメージが強いのですが、ドローンの試験場ができるとは驚きました。
今後は、より筑波に行く機会が増えそうです。

さて、世界中で様々な問題を巻き起こしているドローンですが、練習方法について取り上げている記事は少ないです。
ドローンの操縦はラジコンヘリコプターと比べると格段に簡単(らしい)ですが、やはり陸のラジコンとは異なり、空を飛ぶ乗り物をコントロールするのはかなり難しいです。(例えるなら、昔ゲームで2Dから3Dになってコアゲーマー以外が脱落してしまったようなイメージ)

私は今は主に室内で練習しています。外で練習をしたいのはやまやまなのですが、こういうご時世だし周りの目が気になりますからね。
ただ、私が室内で練習できるのは一人暮らしだからというのもあります。家族と一緒に暮らしていたら、家族はさぞかしよい迷惑だと思います。
そのくらいドローンの操縦は厄介なのです。げしげしと壁や床に機体をぶつけています。

とはいえ、ドローンの発達により、個人が空での遊びはもちろん、空のビジネスを開始できるようになる時代になるのも間違いないでしょう。
参入障壁の高かった空への参加は、私達に多くの恩恵を与えてくれるはずです。

そして、ドローンを扱うにはやはり練習が必要です。

久しぶりのドローンの良いニュースでした。

この記事がお役にたちましたらシェアをお願いします

2015年5月6日水曜日

大山(おおやま)へ行ってきました

公開日：2015年05月06日
最終更新日：2015年06月21日

登山日時

2015/05/05

伊勢原駅 - 大山ケーブル

ゴールデンウィーク4日目に、大山(おおやま)へ行ってきました。

都内から日帰りで行くことのできる人気の山です。
この日は天気が悪かったので、人は少なめでした。

朝早く起きたので、伊勢原駅に着いたのは7時くらいでした。
移動時に財布を出し入れするのが面倒だったので、丹沢・大山フリーパスを購入しました。

伊勢原は池新宿から小田原線で1時間20分くらい。そこからさらにバスで大山に向かいました。

大山

結構急斜面が多く、体力を使います。ペースに気をつけましょう。

行きは途中までケーブルカーを使用しました。

帰りはケーブルカーを使わないで歩きました。

看板では頂上まで90分とありましたが、50分くらいでした。写真撮ったり、休憩を抜けば40分で行けるでしょう。
帰りも登りと同じ道でしたが、スピードがでるので注意が必要です。ストックがあると安全です。
女坂を通って下山しましたが、途中に鹿と遭遇しました。人に慣れてるのか、全然警戒心がありませんでした。