2016年2月26日金曜日

【お知らせ】プログラミングJavaサイトを作成しました

  • 公開日:2016年02月26日

記事概要

告知です。

はじめに

プログラミングJavaというサイトを公開しました。

プログラミングJavaのサイト

サイトを作成した理由

最近久しぶりにjavaでWEBの開発をする機会がありました。
その時に調べたことをまとめてblogで公開しようと思ったのですが、androidに加えて、webのjava技術までこのサイトで公開すると、使いにくくなると思ってjava用のサイトを作成することにしました。

あとは、検索でHITするjavaの情報が古いのばかりで、腹が立ったのも理由です。

扱うコンテンツ

java全般の技術を扱います。android, tomcat, pure java, 環境構築等をメインに扱います。余力があれば、文法、アルゴリズム、デザインパターンなんかも記載できたらいいなと思っています。
とはいえ、やはりandroidがメインになっていくとは思います。このブログで人気の記事は書き直してサイトでも公開するつもりです。

言語

日本語と英語です。他の言語に訳してくれる人がいたら連絡下さい。

開発環境は

railsです。最初はjavaサイトらしくspringで作ろうと思ったんですが、面倒なのでやめました。製作期間は3週間くらいです。

rails(ruby)の記事もまとめて

やります。ちょっと待っててください。

サーバー系の記事もまとめて

セキュリティ系を含めてやる予定です。しばらく待っててください。

広告出したい

連絡ください。

機能追加して

掲示板つくるのでそこに書き込んでください。

まとめ

またandroidのアプリの作成をするので、今後しばらくはandroid系の記事が増えると思います。

そんなわけで今後もよろしくお願いします。

以上です。

運営サイト(railsで作成しています)


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

このエントリーをはてなブックマークに追加

【コラム】アルゴリズムで動く市場は悪なのか

  • 公開日:2016年02月26日

記事概要

コラム記事


2016年になって日経平均は大暴落

2016年に入ってから株式市場が暴落しています。

去年21,000円近くまで上昇した日経平均は16,000円を切りました。

僕の保持している長期投資信託も、一時より結構目減りしています。

さて、今の投資の世界はアルゴリズムを利用してトレーディングが行われていることは多くの人の知るところだと思います。
このことは、アメリカでも問題として取り上げられています。
アルゴリズムを利用したトレードが世界中の市場で混乱が起きている原因だと指摘する批判は多いです。しかし、アルゴリズムで売り買いをコントロールするのはそんなに悪いことなのでしょうか。

アルゴリズムで動く世の中

現在の世の中にアルゴリズムは欠かせません。人々が普段の生活で日常的に利用しているサービスにもアルゴリズムは多く利用されています。

例えばみなさんが普段利用しているamazonや楽天です。物を買うときにログインすると、URLにhttpsという文字が付加されているのが確認できると思います。
これはhttpsプロトコルと呼ばれる技術で、HTTP通信において認証や暗号化を行うために利用されています。

httpsで利用されている詳細なアルゴリズムの説明を省きますが、この技術により私たちはインターネット上で安全に取引を行うことができます。

中には、インターネットを利用していない人もいるかもしれません。でも、銀行のATMは利用していると思います。このATMを使った銀行間の取引には、全銀プロトコルと呼ばれる取り決めが利用されています。
私達がATMを介して銀行間で取引できるのは、このプロトコルで利用されているアルゴリズムのおかげです。

銀行は、長期の祝日等に、システムのメンテナンスをするためにATMを停止するケースがあります。この時は、事前の告知にも関わらず、多くの人から苦情の電話があるそうです。
このように、私たちは便利な生活をアルゴリズムから享受しているのです。

トレードのオートメーション化

株式の世界では、トレードに勝つための技術やテクニックが存在します。
本屋にいくと、多くのテクニカル手法を説明した本が並んでいます。これらは投資家達の経験を体系化した技術です。
一般的に、市場はランダムウォーク(規則性のない動き)であると言われています。しかし一方で、市場で良いパフォーマンスをあげ続け、巨万の富を得ている人も、ごく少数ですが存在するのです。

彼らは、移動平均平均乖離率を利用した逆張りトレード等の手法を利用して株価を推測し、日々市場で取引しています。

今後は、こういった昔ながらの手法で市場に残る人はぐんと減少するでしょう。代わりに、個人でも機械学習とビックデータを用いて株価を推測するのが主流になるのではないでしょうか。
なぜなら、時代が進むにつれ、既存のテクニカル手法より、アルゴリズムや機械学習を利用したほうが予測精度が高くなることは間違いないからです。

また、このことから、アルゴリズムや機械学習の導入により、市場がランダムウォークから規則性を持つ動きになる可能性もあります。
今後はアルゴリズムや機械学習の動きを予測したアルゴリズムや機械学習のトレードも広がるはずです。

まとめ

株価は企業の状態となるべく一致するのが望ましいのは言うまでもないでしょう。投資家は企業から発表された情報で、企業に投資します。
そして、企業は市場から得た資金を元手にして、より高い利益をあげていきます。そして、稼いだ利益を投資家達に配分します。

一方で、トレードで利用されるアルゴリズムは、市場のゆがみや株価の動きから値動きを判断して売買を決めているアルゴリズムが多いようです。否定されるのは当然でしょう。

しかし、予測アルゴリズムを用いても、あくまで予測は予測でしかありません。どんなアルゴリズムを使い、どんなアルゴリズムで機械学習をさせるかは、開発者や使い手次第です。どんなにオートメーション化が進んでも、プログラムの実装方法の最終判断を下すのは人間しかいません。それは人工知能になっても同じことです。

結局のところ、技術というのは使い手次第です。アルゴリズムを用いたから利益があがるのではなく、優れたアルゴリズムを考案することで利益があがるのです。技術はブースター(増幅器)のようなものです。

アルゴリズムを作り上げたのが人間の思考なら、それは市場の動きとして認めて良いのではないでしょうか。
そう自分に言い聞かせて、この荒れた市場の動きを見守りたいと思います。

参考サイト

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

このエントリーをはてなブックマークに追加

2016年2月24日水曜日

【Rails4.2.xx】 Capistrano3でよく発生するエラー

記事概要

capistrano3でよく発生するエラーをまとめた記事です。

環境

  • centos6.5
  • rails4.2.5
  • ruby2.3.0
  • rbenv
  • unicorn

capistrano3とは

capistrano3はデプロイツールです。rubyで記述されているので、railsアプリのdeployと相性が非常に良いです。
ruby以外の言語でも利用できますが、railsだとより多くの機能を利用できます。
公式サイト

エラーについて

capistrano3は便利である反面、うまく動作するまでは、エラーに悩まされます。
特に初心者は、うまく実行できる前に心が折れてしまう可能があります。
なので、よく発生するエラーの修正方法を記載しようと思います。

db:createについて

capistrano3を実行する前には、rake db:createを実行してdatabaseを作成しておく必要があります。
capistrano3は、dbに変更がある場合にdeployと同時にrake db:migrateを実行します。しかし、rake db:createは実行しません。
なので、databaseはあらかじめ作成しておく必要があります。

capistrano3はデプロイ(更新)ツールなので、databaseは作成しません。
なので、rake db:migrateがきちんと動作するように、db:createでdatabaseを前もって作成しておく必要があります。

assetsコンパイルの失敗

はじめてのcapistrano3の実行でassets compileをしようとすると、初回deployで失敗する可能性があります。

この場合、自分でassets compileを実行する必要があります。

{project_folder}/current/

cd {project_folder}/current

// staging
bundle exec rake assets:precompile RAILS_ENV=staging.

// production
bundle exec rake assets:precompile RAILS_ENV=production.

二回目以降は自動でassets compileが実行されるようになります。これはassets_manifest_backupというフォルダが生成されるからです。

また、assets compileは重い処理です。なので、capistrano3でなく手動で実行するのもありだと思います。

assetsフォルダが読みこまれない

nginxとunicornを連携したrailsアプリをcapistrano3でdeployすると、assetsフォルダ配下がブラウザで読みこまれないケースがあります。

これは、pathが{project_folder}/current/public/assets/になってしまうためです。
なので、nginxでassetsファイルのpathを指定する必要があります。

/etc/nginx/conf.d/app.conf

    location ~ ^/assets/ {
        root /var/www/rails/app/current/public;
    }

unicorn startの環境設定

capistrano3-unicornを利用してunicornの起動や再起動を実行している人は多いでしょう。
capistrano3-unicornを使ったunicornの起動では、以下のコマンドが実行されています。

capistrano3-unicorn/lib/capistrano3/tasks/unicorn.rake

execute :bundle, "exec unicorn", "-c", fetch(:unicorn_config_path), "-E", fetch(:unicorn_rack_env), "-D", fetch(:unicorn_options)

見ての通り、unicorn_rack_envの設定が必要になります。この変数は以下のように設定されます。

capistrano3-unicorn/lib/capistrano3/tasks/unicorn.rake

set :unicorn_rack_env, -> { fetch(:rails_env) == "development" ? "development" : "deployment" }

設定がない場合は、developmentで動作するような実装になっています。

なので、development以外の環境で実行する場合は、明示的に指定してやる必要があります。

project_folder/config/deploy/staging.rb

set :stage, :staging
set :rails_env, 'staging'
set :unicorn_rack_env, :staging

{project_folder}/config/deploy/production.rb

set :stage, :production
set :rails_env, 'production'
set :unicorn_rack_env, :production

上記のように変更したら、deployを実行してみましょう。

terminal

cd /vagrant_data/{project_folder}
bundle exec cap staging deploy

INFO [b8410ed9] Running /usr/local/rbenv/bin/rbenv exec bundle exec unicorn -c /var/www/rails/app/current/config/unicorn/staging.rb -E staging -D  as root@192.XXX.XX.XX

きちんとstagingで実行されています。

まとめ

capistrano3は強力なdeployツールです。最初はとっつきにくいしれませんが、慣れると手放せなくなると思います。
私はphpやjavaのdeployでもcapistrano3を利用しています。

本番環境のデプロイは必ず自動化しましょう。できればプロジェクト開始時に設定してしまうのが良いと思います。
プロジェクトの後半になって、deployの自動化を設定しようとしても時間が足りなくて後回しになる可能性があります。

何事も経験です。是非、試してみてください。

以上です。

PICK UP オススメ書籍

運営サイト(railsで作成しています)


関連記事

参考記事

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

このエントリーをはてなブックマークに追加

2016年2月19日金曜日

【コラム】サイバーセキュリティの国家資格の創設検討に思ふこと

2017年にサイバーセキュリティの国家資格の創設が検討されている。
なんともお上らしい考えである。日本人は資格(肩書)が大好きだ。間違いなく人気の資格となるだろう。会社によっては報奨金も設定されるだろう。

こんな資格にほとんど意味が無いことは、作成者自身が一番理解しているはずなだ。なのに、どうしてこのような資格を創設するのだろうか。

セキュリティの資格

2016年現在、国が開催している情報系のセキュリティ系の資格は二種類ある。

  • 情報セキュリティマネジメント
  • 情報セキュリティスペシャリスト

である。

どちらも人気の資格で、かなりの人がセキュリティスペシャリスト、もしくはセキュリティマネジメントと認定されている。

どころが、セキュリティの事件は年々増加している。この資格が新設されても世間からセキュリティの事件は減少しないし、解決もしない。それは自信をもって断言できる。

知識を問うても意味がない

資格は実務経験がないと意味がない。

よく言われる言葉だ。

エンジニアにとって知識とは道具に過ぎない。道具は問題を解決するためにある。

例えば、セキュリティの基礎知識に公開鍵と秘密鍵というものがある。
これらはセキュリティの試験でない基本情報試験などの簡単な試験でも問われる知識だ。

しかし、実際にこの知識を用いてlinuxで公開鍵認証による SSH ログイン設定をしたことがある人は何人いるだろうか。

おそらくほとんどの人は設定をしたことはおろか、何をするかのイメージもわかないだろう。

ソフトウェアとは命令コードの集合体だ。知識や言葉だけでは解決できない。実際に手を動かしてみないと何もならないのである。

Don't think. Touch. (考えるな。触れ。)

本物のセキュリティ技術を身につけたいなら、WEBアプリを開発し、自分でサーバーの構築をしてWEBアプリを公開するのが最良の方法だ。
そしてWEBアプリとサーバーをメンテナンスし続けること。
その過程では、色々な問題が起きるはずだ。それを解決していくことで本物のセキュリティスペシャリストに近づくことができる。

誰だって最初からロジャー・フェデラーやリオネル・メッシになることはできない。多くの知識と練習と経験を経て、本物になることができる。

まとめ

僕は資格試験そのものを否定しているわけではない。
僕も新人の頃は基本情報、ソフトウェア開発者試験、oracle, LPIC等色々な試験を受けてきた。
TOIEC等の専門外の試験は未だに受験している。

ただ、サイバーセキュリティの国家資格の学習をするくらいなら、サーバーの設定をしてアプリを公開して欲しい。そのほうが評価できるし、技術もあがる。面接だって楽勝だし、職にも困らないだろう。

もちろん、この資格が国の大きな財源となり、セキュリティに長けたエンジニアを増やす資源をプールすることが目的なら大賛成である。

これ以上試験の創設前に意見を言っても意味がないので、話はここまでにしようと思う。

こんなことを語る僕も、資格大好きな日本人の一人なのだろう。

他のコラム

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

このエントリーをはてなブックマークに追加

2016年2月15日月曜日

【Blogger】facebookいいね(Like)ボタンの設置 記事別にボタンを設置する

  • 公開日:2016年02月15日

記事概要

bloggerのカスタム方法です。

環境

  • Blogger

はじめに

これまであまりしなかったBloggerのカスタマイズを開始しました。
Bloggerのカスタマイズの情報は少ないので、積極的に掲載していこうと思います。
今回は、未設置だったfacebookいいね(Like)ボタンの設置方法を記載します。

facebookいいね!ボタンのない状態のダメ男のblog

facebookいいね(Like)ボタン

facebookいいね(Like)ボタンは、faceook for developersのLike Button Configuratorの画面から作成することができます。

デフォルトの設定ではいいね!とシェアが両方表示されている。

このBlogでは、facebookいいね(Like)ボタンをカスタマイズして利用します。Layoutをbox_countに変更し、Include Share Buttonのチェックを外します。

変更が画面に反映される

カスタマイズが終了したら、Get Codeボタンをクリックします。

htmlに埋め込むソースコードが表示される

コードが表示されるので、コピーして適当なテキストに貼り付けます。

コードの変更1

facebookのいいね!コードは生成できました。しかし、このままでは問題が発生して利用することはできません。
このままだと記事ごとのいいね!ボタンとしては機能しません。blog全体のいいね!ボタンになってしまいます。
なので、記事ごとにいいね!がクリックできるように修正します。

■Before

facebook like code

<div class="fb-like" data-href="https://developers.facebook.com/docs/plugins/" data-layout="box_count" data-action="like" data-show-faces="true" data-share="false"></div>

■After

facebook like code

<div class="fb-like" expr:data-href="data:post.canonicalUrl" data-layout="box_count" data-action="like" data-show-faces="true" data-share="false"></div>

expr:data-href="data:post.canonicalUrl"にすることで記事ごとのいいね!ボタンを設置できるようになります。

コードの変更2

次の問題は、取得したコードをそのままtemplateに貼り付けると、「The reference to entity "version" must end with the ';' delimiter」というエラーが発生してしまうことです。

これはxmlのparseに失敗すると発生するエラーなので、以下のように修正します。

■Before

facebook like code

<script>(function(d, s, id) {
  var js, fjs = d.getElementsByTagName(s)[0];
  if (d.getElementById(id)) return;
  js = d.createElement(s); js.id = id;
  js.src = "//connect.facebook.net/ja_JP/sdk.js#xfbml=1&version=v2.5";
  fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>

■After

facebook like code

<script>(function(d, s, id) {
  var js, fjs = d.getElementsByTagName(s)[0];
  if (d.getElementById(id)) return;
  js = d.createElement(s); js.id = id;
  js.src = "//connect.facebook.net/ja_JP/sdk.js#xfbml=1&amp;version=v2.5";
  fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>

パラメーターを&amp;に変更することでxmlのparseエラーが発生しなくなります。

テンプレート変更

上記の修正が完了したら、コードをテンプレートに貼り付けます。

template

<script>(function(d, s, id) {
  var js, fjs = d.getElementsByTagName(s)[0];
  if (d.getElementById(id)) return;
  js = d.createElement(s); js.id = id;
  js.src = "//connect.facebook.net/ja_JP/sdk.js#xfbml=1&amp;version=v2.5";
  fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>

<div class="fb-like" expr:data-href="data:post.canonicalUrl" data-layout="box_count" data-action="like" data-show-faces="true" data-share="false"></div>

他のSNSボタンのデザインに合わせてcssを変更する場合は、divで囲むと良いでしょう。

動作確認

テンプレートを保存したら上記の変更がきちんと行われていることを確認します。

facebookいいね!ボタンが設置されたダメ男のblog

うまく表示されています。

まとめ

Bloggerの情報は少ないので、プログラミング能力があると便利です。
自由度が高く、SEO対策をしなくてもgoogle検索に強いので、エンジニアには最高の無料Blogです。しかし、普通の人には少しハードルが高いかもしれません。
ただ、どの無料ブログよりもWEBアプリに近いカスタムができるので頑張ってみてください。

以上です。

関連記事

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

このエントリーをはてなブックマークに追加

2016年2月12日金曜日

【コラム】政治家でもわかるITエンジニアが危機的に不足している理由

記事概要

コラム記事。


オバマ大統領もプログラミングを学んでほしいと発言

最近、仕事関連の知り合いやプロマネ達に会うたびに「良いエンジニアはいないか」と尋ねられる。
そう言われても、今のITエンジニア不足は深刻だ。人がいないので金でも解決できない。どうしようもない。

しかし、こんな状況でも欲しがる人材のレベルは高望みだ。
コミュニケーションが取れて、プログラムが書けて、サーバの構築ができて、単価が安くて、意欲のある若い人材。
つまり、低賃金労働で口答えをしないスーパーマン。

当たり前だが、そんな都合のよい人材などいない。普通のエンジニアさえ見つけるのも困難なのである。そもそも今、ITエンジニアになりたい人自体が少ない。プログラマーにならないかと新卒を誘うと、露骨に顔をしかめる子も多い。

世界中の国や企業でプログラムができる人材を探している。そして、育てようとしている。だが、需要が供給を遥かに超えてしまっている。日本は深刻なレベルだ。

ではどうしてこんなにもITエンジニアが不足しているのだろうか。理由は色々とある。
僕は(今のところ)日本のITエンジニアだから、海外のことは詳しくわからない。でも、日本がひどいIT人材不足に陥ってしまった理由はわかっているつもりだ。
せっかくなので、自分の経験をまじえて説明していこうと思う。

35歳限界説

少し前まで「35歳限界説」という言葉が存在していた時代があった。
この言葉は、ITエンジニアは激務だから、それ以上の年齢だと仕事に体が耐えることができないという労働環境から生み出された言葉だ。

実際、20世紀のエンジニアの仕事は、今以上に激務だった。
徹夜は当たり前。多くの仕事と顧客の無理難題を押しつけられ、寝に帰るだけの毎日を過ごす。

一方で、仕事の内容はスカスカだ。朝からプロジェクトの会議に出席しっぱなし。ようやく自分の仕事が開始できるのは定時後である。
そんな昔のアホ自慢をしてくる管理職は未だに多かったりする。

僕が就職したのは21世紀だが、その時の某企業での新卒の面接時のやりとりはいまだに覚えている。

面接官:「通勤時間長いね(1時間半くらい)」
Masa:「体力には自信があるので問題ありません」
面接官「11時(23時)に仕事が終わって家に帰ったら午前様だよ?」
Masa「忙しい時期が多いのでしょうか」
面接官「いやいや。定時はあってないようなものだから」
Masa「...は?」
面接官「この業界で定時に帰る人なんていないよ。甘いよ。」

僕がこの企業の内定を蹴ったことは説明するまでもないだろう。ちなみにこの企業は倒産して、もう存在しない。

もちろん「35歳限界説」も完全な都市伝説である。

グローバルバカの出現

上述したように、昔のITエンジニアは今よりはるかに激務だった。当然のことながら、離職率も高かった。
一人前のITエンジニアになるまでには時間がかかる。そう簡単に力はつかない。
しかし、さらに追い打ちをかけるように世の中は動いていった。

グローバル化である。

パソコンの能力の向上とインターネットの急速な発展は、先進国の人から単純労働を奪い始めた。
発展途上国の人のほうがはるかに単価が安く、人件費を抑えられるからだ。

そして、この仕組みに気づいた意識高い系のビジネスマン達は、オフショアという仕組みを取り入れて大きな利益を出すようになった。
オフショアは人材派遣のグローバル版である。意識高い系人材派遣ともいう。
そしてついには、その意識高い系のビジネスマン達はIT業界にも口をだしはじめた。

「プログラムのような下等な仕事は単価の安い発展途上国の仕事になる。先進国の人材は上流の設計だけをやれば良い。」

なぜこういう意見が生まれたのか、僕にはわからない。推測だが、

発展途上国の人間でもできる → 単価の安い下等な仕事

という差別的な考えが彼らの頭の中にあったに違いない。だから、このような間違った判断を下したのではないか。
意識高い系のビジネスマンエリート様達には

発展途上国の人間がプログラミングをできるようになる → その国の技術、教育、賃金が上昇し国が発展する

という視点が完全に抜け落ちていたのだ。

だが、おそるべきことにこの意見は世間やIT業界で受け入れられた。プログラムは3年も書けば十分とされ、プログラマーとして働く人は、いずれSE(システムエンジニア)に昇格するのが当然とされるようになった。肩書が職能でなく、序列を生みだしてしまった。そして、これがとんでもない悲劇の引き金だった。

プログラムを書けないIT屋の増加

「プログラムのような下等な仕事は単価の安い発展途上国の仕事になる」

この考察は悪魔の理論だった。しかし、論理的思考法を得意とするエリートコンサルタント様達が賞賛したこの意見は、業界の常識として溶け込んでいった。
プログラマーの単価はあがらなくなった。単価をあげるには、SE(システムエンジニア)になり、PM(プロジェクトマネージャー)になり、最後はコンサルを目指すことが理想のキャリアパスとみなされるようになった。ここまでくると「つける薬はない」と今になっては思うが、当時は当たり前だった。

当然のことながら、会社は利益を追い求める。それが普通だし、そうしなければいけない。
そして、当然のようにプログラムを書かないエンジニアが生まれるようになった。そして、それが当たり前になるのに時間はかからなかった。

本来、エンジニアにとって大切な力は、システムの理解力である。
「仕様(要件)をコードでイメージし、システムを設計していく。」これがなにより大切なのだ。

英語や中国語等の日本語以外の言葉を話せる人ならわかるだろう。無意識に他言語での表現が頭や口に浮かぶあの状態である。ITエンジニアはプログラミング言語を介してその状態にならないといけないのだ。

しかし、この業界の常識、特に日本のslerは「仕様(要件)をもとにシステムを設計し、最後にコードに落とし込む」というやり方をしている(た)。
こうなると当然、コードで実装できない仕様が発生する。このシステム設計の誤りが手戻りを発生させ、度重なる会議と打ち合わせを必要とするようになり、実装工数が圧縮され、デスマーチとよばれる現場を生み出すのである。

しかし、Googleやfacebook等の一部の企業を除く多くの企業はこの基本を理解せず、システムの理解力に長けたプログラマーを求めなかった。彼らが求めたのは、単価の高いSE(システムエンジニア)だった。そして、彼らにコミュニケーション能力を求めた。さらには、右も左も分からぬ新人にSEという肩書を記載した名刺を渡した。そしてそれは多くの炎上プロジェクトを生み出す地獄の切符となった。

炎上したプロジェクトは悲惨だ。ひどい会社だとプロジェクトに関係ない多くのエンジニアまでが巻き込まれる。そして心身を削られ、業界から去っていく。才能があるのに、才能が開花する前に去ってしまう人を多く見てきた。 力がある人でも、多くの仕事を押し付けられて、壊れて去っていった人もいる。

また、ベトナムや中国等の国へのオフショアも実施されるようになった。ますますプログラムは軽視されるようになった。
だが、ほとんどのプロジェクトは思ったより安くはならなかった。それどころか、品質が悪く長期的にコストがかかるのが現実だった。

デフレ

ベトナムや中国等の国へのオフショアが実施されるようになったが、数年も経つと問題が浮上してきた。
発展途上国の人の賃金があがってきたのである。

一方で日本はデフレのままだった。日本人の1/5程度の給料で働いていた途上国の人達が、日本人の半分ほどの賃金がかかるようになったのである。日本以外の世界は成長を続け、インフレになっていた。つまり、採算がとれなくなってきてしまったのである。

なぜオフショアを推進していたか。それは安いからである。
しかも海外のITエンジニアは、日本のITエンジニアとは大きく労働感が異なる。日本人労働者のようにサービス残業などしない。
プロマネの中には、海外の奴らは残業をしないなどと怒る人もいる。これは当たり前だ。日本が異常なのである。

さらに、オフショアのシステムの品質は悪いことが多い。オフショアのプロジェクトでは、ブリッジSE(システムエンジニア)と呼ばれる異なる国の言語を話せるエンジニアが招集されるのが普通だ。しかし、うまくいっている事例は少ない。当たり前である。問題なのは言葉の違いでなく文化の違いにあるからだ。

スマホ襲来

(日本にとって)悪いことは続く。アップルがスマートフォンを発売したのである。
この製品はユーザーより、エンジニアにとって衝撃的だった。なぜなら、プログラミング力があれば、自分一人でも世界で勝負できるプラットフォームが用意されていたからだ。

さらに、スマホの進化はとんでもなく速かった。これまで以上の速度で技術が進化するようになった。

この頃になると、これまでオフショアでしかお金を稼げなかった途上国のエンジニア達もオリジナルのアプリ開発に参入するようになってきた。これまでの下請けのノウハウが蓄積されたのである。

IT市場には、先進国のITエンジニアだけでなく途上国のエンジニアも参入するようになり、さらに飛躍的に技術力が向上するようになった。今もなお、一年前の技術が時代遅れになるほどの速度で進化を続けている。トーマス・フリードマンの「フラット化する世界」が現実になりはじめたのだ。

しかし日本の意識高い系のビジネスマン様達は、グローバル化なので英語化が重要だと声を上げるようになっていた。相変わらず理解力がないままだった。

開発の世界では進化のスピードについていくためにオープンソースが一般的となり、世界中の頭脳の集合知がさらに優れたツールを生み出していった。優れた開発者なら一人でスマホ開発、web開発、サーバー構築まですることが可能になった。わずか数人しかいないのに、何百億という価値をもつ企業が現れはじめた。instagramやSnapchatが良い例だ。

だが、ほとんどの日本の企業は既存のやり方を変えなかった。変わらなくともなんとかなると思っているのか、それとも変化に気づいていないかのどちらかなのだろう。日本の技術者で現状を認識しているのは、未だにごく一部である。

日本語に翻訳されない

上記の要因により、加速度的に技術が向上し変化するようになった。しかし、日本のほとんどのITエンジニア達は、変化を嫌って追わなかった(追えなかった)。なにより企業が変化とリスクを嫌い、実績ある既存の技術を使い続けた。

このことは、最新の海外の技術書の翻訳を少なくさせた。売れないのだから当たり前だ。翻訳だってビジネスだ。海外で賞を取るような優れた技術書も現在はほとんど翻訳されなくなっている。また、翻訳されたころには仕様の変更された古いバージョンということも多い。

最新技術を知るには、英語力が必要になってしまった。今、日本の技術者達のレベルは、人によりかなり顕著に差がつき始めている。英語力と技術力につながりができてしまったのである。日本の意識高い系のビジネスマン様達の言葉は、悪い意味で的中してきている。

そして誰もいなくなった

長い労働時間、すぐに変化する技術、予測不可能な将来、安い給料。気がつけばITエンジニアを志す新卒の日本人は激減した。
ワークライフバランスが提唱される時代に、日本のITエンジニアの労働環境はそぐわない。時代と真逆だ。人が集まるわけがない。

シリコンバレー等の海外に行くエンジニアも増えた。当然だ。向こうのスターエンジニアは億を稼ぐ。労働環境も優れている。プロ野球選手と独立リーグぐらい待遇が違う。

未だに日本では、「ボランティアでセキュリティ対策をできるエンジニアが必要だ」などと発言しては炎上している経営者がいる。2030年には既存の半分の企業が人材不足で倒産すると予想されているが、IT業界はもっとひどいことになるはずだ。

まとめ

タイトルが「政治家でもわかるITエンジニアが危機的に不足している理由」なので、政治を叩くコラムだと思った人も多いかもしれない。だが、全然違う。このコラムの趣旨は、ITに縁の遠い政治家でも分かるように、IT人材が枯渇している理由を説明しようということにある。
そもそも日本のソフトウェア産業に競争力がないのは政治家のせいではない。多くの要因が重なって今の状況があるのだ。

最近ではバズワードとしてIoTが流行っている。ドイツでは『インダストリー4.0』としてドイツ政府が本腰を入れて取り組んでいる。だが、このままだとドイツの試みは失敗に終わるだろう。IoTは産業の核とはならない。日本でも、ものづくりの得意な日本の巻き返せるチャンスと思っている人がいるみたいだが、可能性はほとんどない。IoTの本質はものづくりでなく「情報産業」である。ろくに人材のいない日本にはチャンスは少ないと思う。

ITエンジニアの不足を解消するのは難しい。若い人材そのものが減っている。若い人のメンターになれるような人材も限られている。完全に負のスパイラルに入っている。

全てを解決できる銀の弾丸はない。地道に業界そのものを変えていくしかない。労働環境、給料の改善はもちろん、技術への取り組み方、肩書で決まる賃金、下請けへの丸投げも変えていく必要がある。

国境の壁の低い仕事なので、育った人材が海外に流出するリスクもある。だが、それでも力のある人材を育てないといけない。本格的にITエンジニアの力が求められるのはこれからの時代なのだ。

他のコラム

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

このエントリーをはてなブックマークに追加

2016年2月6日土曜日

【Rails4.2.xx】 Capistrano3を使用する

記事概要

capistrano3の使い方をまとめた記事です。

read in English

環境

  • rails4.2.5 & centos6.5
  • ruby2.3.0
  • rbenv
  • unicorn

capistranoとは

capistrano3はデプロイツールです。rubyで記述されているので、railsアプリのdeployと相性が非常に良いです。
ruby以外の言語でも利用できますが、railsだとより多くの機能を利用できます。

なぜ使うのか

デプロイ作業は大変な作業です。一方で繊細な作業でもあります。
アプリによっては、多くの時間をリリース作業に割いているかもしれません。
capistrano3を利用すればコマンドを叩くだけでアプリをリリースできます。
セキュリティの面を考慮しても、デプロイは自動化するべきです。

cap install

では、capistrano3のインストール作業からはじめていきたいと思います。

必要なgemをGemfileに設定します。

{project_folder}/Gemfile

group :development do
  # Access an IRB console on exception pages or by using <%= console %> in views
  gem 'web-console', '~> 2.0'
  gem 'capistrano', '~> 3.2.1'
  gem 'capistrano-ssh-doctor', '~> 1.0'
  gem 'capistrano-rails'
  gem 'capistrano-rbenv', github: "capistrano/rbenv"
  gem 'capistrano-bundler', "~> 1.1.0"
  gem 'capistrano3-unicorn' # unicornを使っている場合のみ
end

記述したgemをinstallします。

terminal

cd {project_folder}

rbenv exec bundle install

gemのinstall完了後にコマンドを叩きます。

terminal

cd {project_folder}

bundle exec cap install

mkdir -p config/deploy
create config/deploy.rb
create config/deploy/staging.rb
create config/deploy/production.rb
mkdir -p lib/capistrano/tasks
Capified

capコマンドで自動deployに必要なファイルが作成されます。
上記以外にもdelpoy環境が必要な人はファイルを手動で増やします。
私の場合は、ローカルで開発、 stagingで検証、productionで本番を扱っています。
なので、デフォルトのままです。
では、deployの詳細な設定をしていきましょう。

Capfileの設定

まずはCapfileを設定します。
rbenvを利用するので、requireを追加します。

{project_folder}/Capfile

require 'capistrano/rbenv'

railsで利用しているrubyのバージョンを確認します。

terminal

[root@vagrant-centos65 ~]# ruby -v
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux]

Capfileにrailsで利用しているrubyのバージョンを設定します。

{project_folder}/Capfile

require 'capistrano/rbenv'

set :rbenv_ruby, '2.3.0'

次に利用しているrbenvのパスを記述します。

terminal

[root@vagrant-centos65 ~]# which rbenv
/usr/local/rbenv/bin/rbenv

binの前の/usr/local/rbenvまでを設定します。

{project_folder}/Capfile

require 'capistrano/rbenv'

set :rbenv_ruby, '2.3.0'
set :rbenv_custom_path, '/usr/local/rbenv'

Bundlerを使ってgemを管理します。

{project_folder}/Capfile

require 'capistrano/bundler'

続いてdeploy時に必要な処理を記述します。
assets compile, unicornの再起動, DB migrate, site-mapの更新は自動化しておきたいところです。
下記のサンプルでは、site-map以外全ての設定を行っています。


require 'capistrano/rbenv'

set :rbenv_ruby, '2.3.0'
set :rbenv_custom_path, '/usr/local/rbenv'

require 'capistrano/rails/assets'
require 'capistrano/rails/migrations'
require 'capistrano/rails'
require 'capistrano/bundler'
require 'capistrano3/unicorn'

config/deploy.rb

続けてdeploy.rbの設定を行います。このファイルにはdeployの共通処理を記述します。
まずはgit情報を設定します。

{project_folder}/Capfile

set :application, 'sampleweb'
set :repo_url, 'git@xxxxxxxx:test/sample_web.git'

# Default value for :scm is :git
set :scm, :git

capistranoでは、git cloneでソースコードを取得します。
サーバーでユーザーがソースコードを取得できるよう、前もって設定する必要があります

rbenvはシステムインストールを利用します

{project_folder}/Capfile

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

シンボリックリンクを利用するパスを設定します。

{project_folder}/Capfile

set :linked_dirs, %w{bin log tmp/pids tmp/cache tmp/sockets bundle public}

unicornのpidを配置するファイルを置きます。

{project_folder}/Capfile

set :unicorn_pid, -> {"#{shared_path}/tmp/pids/unicorn.pid"}

デフォルトの環境設定を行ないます。

{project_folder}/Capfile

set :default_env, { path: "/usr/local/rbenv/shims:/usr/local/rbenv/bin:$PATH" }

deploy時にassets compileを実行する処理を記述します。

{project_folder}/Capfile

  namespace :assets do
    Rake::Task['deploy:assets:precompile'].clear_actions
    
    desc "Precompile assets"
    task :precompile do
      puts "-----nothing-------"
    end
  end

deploy時にunicornを再起動するように処理を記述します。

{project_folder}/Capfile

  desc 'Restart application'
  task :restart do
    on roles(:app), in: :sequence, wait: 5 do
      invoke 'unicorn:restart'
      # Your restart mechanism here, for example:
      # execute :touch, release_path.join('tmp/restart.txt')
    end
  end

deploy環境設定

最後に、環境ごとにdeployファイルを設定します。
サンプルとして、staging.rbを設定します。

私は検証環境としてvagrantを利用しています。なので、sshでvagrantにログインするようにします。

{project_folder}/config/deploy/staging.rb

role :app, %w{root@192.168.33.50}
role :web, %w{root@192.168.33.50}
role :db,  %w{root@192.168.33.50}

set :ssh_options, {
  verbose: :debug,
  auth_methods: %w(password),
  password: "vagrant"
}

ssh接続でvagrantにログインする設定です。今回は同一サーバーにdeployをしてみます。

deployテスト

deployのテストをします。

terminal

cd {project_folder}

bundle exec cap staging deploy:check

エラーが発生した場合は、エラーを修正してください。うまくいかない場合は、実行ユーザーのpermissionに注意を払ってください。実行ユーザーにはroot権限を設定することをオススメします。あと、必ずgit cloneができるように設定しておいてください。

terminal

D, [2016-02-01T08:48:42.485315 #11434] DEBUG -- tcpsocket[3fe196317614]: received packet nr 55 type 96 len 12
I, [2016-02-01T08:48:42.485343 #11434]  INFO -- net.ssh.connection.session[3fe1963eb554]: channel_eof: 7
D, [2016-02-01T08:48:42.485384 #11434] DEBUG -- tcpsocket[3fe196317614]: received packet nr 56 type 97 len 12
I, [2016-02-01T08:48:42.485407 #11434]  INFO -- net.ssh.connection.session[3fe1963eb554]: channel_close: 7
D, [2016-02-01T08:48:42.485469 #11434] DEBUG -- tcpsocket[3fe196317614]: queueing packet nr 46 type 97 len 28
INFO [ca5786bf] Finished in 0.034 seconds with exit status 0 (successful).

うまくいったので、実際に本番deplyをします。

本番deploy

本番deployをします。せっかくなのでログを載せます。

terminal

I, [2016-01-26T06:40:47.922269 #745]  INFO -- net.ssh.connection.session[3fdd4a672b9c]: channel_data: 66 29b
DEBUG [159535d3]    Successful ping of Google
D, [2016-01-26T06:40:47.923078 #745] DEBUG -- tcpsocket[3fdd4a0a92ec]: received packet nr 465 type 94 len 44
I, [2016-01-26T06:40:47.923165 #745]  INFO -- net.ssh.connection.session[3fdd4a672b9c]: channel_data: 66 27b
DEBUG [159535d3]    Successful ping of Bing
D, [2016-01-26T06:40:47.923676 #745] DEBUG -- tcpsocket[3fdd4a0a92ec]: received packet nr 466 type 98 len 44

... // something 

INFO [db1051b1] Finished in 0.102 seconds with exit status 0 (successful).

これだけでリリース完了になります。

まとめ

capistrano3は強力なdeployツールです。最初はとっつきにくいしれませんが、慣れると手放せなくなると思います。
私はphpやjavaのdeployでもcapistrano3を利用しています。

本番環境のデプロイは必ず自動化しましょう。できればプロジェクト開始時に設定してしまうのが良いと思います。
プロジェクトの後半になって、deployの自動化を設定しようとしても時間が足りないと騒いで後回しになる可能性が 高いと思います。

何事も経験です。是非、試してみてください。

以上です。

PICK UP オススメ書籍

運営サイト(railsで作成しています)


関連記事

English

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

このエントリーをはてなブックマークに追加

2016年2月5日金曜日

【コラム】Ruby on Railsが向上させたのは生産性でなく技術力

Ruby on Railsの公式サイト画像。バージョン5のサンプル動画が公開されている。

Ruby on Railsのversion5の公開が迫っている。目玉の新機能としてチャットが簡単に制作できるAction Cable機能が実装された。Action Cable機能を使えば、RailsにWebSocketを組み込むことができる。
この機能を使えば、2,3人のスタートアップでも、Lineのようなリアルタイムのチャット機能を組み込める。今後は、チャット機能を備えたアプリが増えるのではないだろうか。

さて、高い生産を売りにしてきてここまで発展してきたRailsだが、実際は生産性はそこまで高くはない。 それよりもRailsの功績は、一人が個人で扱える技術を高めたことにある。

Rails初期

私がはじめてRailsに触れたのはversion0.3の時だったと記憶している。
5分だが10分でweb画面が作成できるという動画を発見し、すぐにRailsに手を出したのだ。

しかし、いじったのは2日程度であったと思う。期待はすぐに失望へと代わった。当時デファクトになっていたjavaのstrutsとの完成度の違いは明らかだった。

過大広告のゴミフレームワーク

私はそう結論を下すと、再びjavaのwebフレームワークでwebサイトを作成する日常へと戻っていったのだ。

Rails3の登場

私がRailsを本格的に使い始めたのは、Rails3になってからである。
それまでは利用しようと考えるほどの魅力を感じなかった。iphoneアプリやandroidアプリ開発という選択が生まれたことで、WEB開発自体に興味を無くしていたことも大きな理由である。

しかし、スマホアプリを開発していくうちにWEBAPIを高速に開発する必要性を感じるようになった。だが、当時のjavaのフレームワークの実装のコストは大きすぎた。そこでperlやphpを利用したが、いまいちしっくりこなかった。色々とやっているうちに、再びRailsが候補になった。

既にRailsはversion3になっていた。私はまず簡単なWEBアプリを作成し、Herokuにあげてリリース作業までを試してみた。

下した結論は合格。これはjavaやphpをすぐに超えるだろう。そう判断を下すには十分の完成度だった。
実際、Railsをversion3から使い始めた開発者は多いのではないだろうか。

意外な副作用

Railsを使ってアプリを作成するようになったが、多くの問題点に遭遇することになった。
思ったように素早く開発を進めることができないのである。

もちろん、ある程度の力量が身につくまでは、調べながらの開発になるのは当然だ。
だが、Railsのversionによって発生するエラーの解決はひどく骨の折れる作業だった。

さらに、利用したい機能のgem(パッケージ)を発見しても、インストールがうまくいかないことも多かった。慣れ親しんだjavaやphpを使うべきではないかと思うことも多々あった。そして、一つの結論に至った。

windowsやmacの環境に頼るのをやめて、Linuxを利用しよう。

Rails on Linux

windowsやmacを使わないでLinuxメインで開発を行う。これが私の出した結論だった。
Railsは確かに便利だ。
だが、問題が発生するとLinuxの知識が求められることが多い。リリースするときも、javaのようにwarを変更したり、phpのようにファイルを置き換えるだけでは不十分なのである。Railsを使うにはRailsのバージョンアップについていくだけの能力が必要だ。 そしてそれには、Linuxの知識が必要である。

また、ちょうどその頃、vagrantという仮想環境をwindowsやmacで利用できるツールが生み出された。僕はこのツールを利用し、Linuxを本格的に学習することにした。

この考えは大当たりだった。私はRubyとRailsの力だけでなく、Linuxの理解をさらに深めることができた。数をこなすうちにRailsでバグを見つけても、エラー内容から自分で解決できるようになった。

基礎が大事

建物を建てる時は基礎工事が大切だ。
作る建物の種類に応じて利用する基礎を適切に選択する必要がある。

WEBアプリも同じだ。Railsはあくまで建物である。基礎部分にあたるサーバーの構築が重要になる。
Railsを動かすのにwindowsサーバーを使うケースは少ないだろう。また、LAMPのみのシンプルな構成で終了するアプリも少ないだろう。

RailsアプリのサーバーにはNginxとunicornを使うはずだ。最近のアプリを構築するならElasticsearch, Redisも導入するかもしれない。(RedisはRails5の新機能Action Cableに必須である)。構成管理にはchefを用いるかもしれない。

Railsを使いこなすためには、学習するしかない。新しい知識も古い知識も両方必要である。そして、その過程で得た知識は、エンジニアとしての基礎能力を飛躍的に向上させてくれる。

そして、基礎能力の向上は、Railsの力を最大限に引き出し、生産性が大幅にアップするのである。

まとめ

Railsの魅力は生産性にあるという意見は未だに根強い。
実際、WEBのスタートアップではRailsを採用することが多い。もし、あなたが今CEOとしてスタートアップを考えているなら、ネットで生産性が高いと噂のRailsを使ってWEBサービスを立ち上げようと考えているかもしれない。

だが、それは間違っている。

Railsの生産が高いのではない。Railsを使ってWEBアプリを組み上げられるエンジニアの生産性が高いのである。

良くも悪くもRailsを使いこなすためには、かなりの時間をコーディングだけでなく、サーバー設定や環境の自動化等の学習に費やす必要がある。ドキュメントを読んですぐうまくいくことはない。膨大な知識と経験の積み重ねが必要になる。

Railsはドラゴンボールでいう超聖水のようなものだ。悟空がカリン様との超聖水争奪戦により自然に力が養われたように、Railsを使って環境と格闘しているうちに、現代のエンジニアに必要な力が養われていくのだ。

生産性10倍の言葉に飛びつき、Railsの学習を開始し、絶望してやめた人も多いと思う。
だが、そういう人にこそもう一度Railsに挑戦して欲しい。その過程で身につけていった力こそが、世界のスタートアップで戦うことのできる力なのである。

他のコラム

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

このエントリーをはてなブックマークに追加
Related Posts Plugin for WordPress, Blogger...