Lチカ開発ブログ

https://l-chika.com/の開発ブログ

Railsアプリケーション構築時に初期にしたこと

Railsでアプリケーション作成後に、ついつい忘れがちになるのでメモ。

前提

環境、Railsアプリケーションの作成はこちら。

l-chika.hatenablog.com

手順

やったこと

  • Timezone: アプリケーションとDB保存時の時間を日本時間にする
  • I18n:文言の日本語対応

変更前

$ ./bin/rails c
> helper.number_to_human(1234) 
=> "1.23 Thousand"

> Time.current
=> Tue, 24 Jan 2017 01:32:15 UTC +00:00

> ActiveRecord::Base.default_timezone
=> :utc

> MyApp::Application.config.active_record.default_timezone
=> nil

TimeZone

$ vim  config/application.rb
  class Application < Rails::Application
    config.time_zone = 'Tokyo'
    config.active_record.default_timezone = :local

    config.i18n.default_locale = :ja
    config.i18n.load_path += Dir[Rails.root.join('config', 'locales', '**', '*.{rb,yml}').to_s]
  end

locale

$ vim Gemfile
gem 'rails-i18n', '~> 5.0.0'
$ bundle install --path=vendor/bundle/

確認

$ ./bin/rails c
> helper.number_to_human(1234) 
=> "1.23 千"
> Time.current
=> Tue, 24 Jan 2017 10:31:46 JST +09:00

> ActiveRecord::Base.default_timezone
=> :local

> MyApp::Application.config.active_record.default_timezone
=> :local

ちなみに

この設定をしても、ActiveRecordの保存等がJSTにならない場合は、OSのタイムゾーンUTCになっている可能性が高い。 その場合は、OSのTimeZoneをJSTに変更する。

Ubuntu_14.04の場合はこちらを参考。

www.server-world.info

関連する書籍

はじめての「Ruby on Rails」5 (I・O BOOKS)

はじめての「Ruby on Rails」5 (I・O BOOKS)

「論語と算盤と私」を読んで

本書はスタートアップで働く人は一読してみると良いと思う。共感と、為になる思考が身に付く。

競走馬の騎士を目指し断念し、東大からコンサル、スタートアップの起業、一部上場企業の代表取締役を経験した著者が、企業活動や企業を取り巻く環境、企業に携わる個人がどうあるべきかをまとめ、自分なりの経営観を整理したもの。

どんな人向けか

個々人の「経営観」を築く参考

経営者、起業を志すひとだでけなく、スタートアップで働くメンバー層や大手企業でスタートアップへの転職等のキャリアに悩む人にも多いに学ぶべきことがある内容だと思う。

と感じたのは、スタートアップとひと口にいっても色々なパターンがあり、またその経営者によって状況というのは大きく異なる。それのメンバーとしてただ受け入れるのでなく、自分で経営者がどう考え、会社の中で自分がどうあるべきかを考えさせてくれる。

各章の気になったところ・どう読んだか

第1章 職業としての経営者とリーダーシップ

企業の成長ステージと経営者に求められるスキルセット・マインドセットを経営者の3類型を定義され、そのステージを前提として経営者に求められるスタイルが語られている。

良い組織というのは、それぞれのが自分の現状の役割よりも一段上の立場の視座を持つことが大事だというけれど、ここでは経営者という「意思決定の難しさ」という改めて認識するとともに、自分の組織のことをまざまざと感じさせらた。

第2章 集団・企業が陥る自己矛盾

上場企業の経営者は従業員と株主の中間管理職という側面があり、異なる利害を持つステークホルダーを同じ方角に向ける務めがある

自己資本のみと、外部資本があるスタートアップを経験した自分としても共感できる内容。

  • 「ミッション」とは何のためにその組織が存在するのかを宣言し、進路を指し示す羅針盤となるもの
  • 事業にひも付いたミッションの求心力が強いほど、新たな事業への転進が難しくなる
  • ミッションの本質は文言そのものよりも、それを伝える過程にこそある

ミッションとは、事業のミッションと組織のミッションの違いとは、ということを丁寧に説明され、ミッションに対する大切さをより深くするとともにそれが持つ役割をもう一段理解することができた気がする。

第3章 起業・スタートアップの環境変化

外部から資本を調達するということは、かように重層的な投資家たちの食物連鎖のなかに組みこまれることを意味する

外部資本のあるスタートアップがほとんどだと思うので、これは本当に業界あるあるかも。

第4章 成熟・衰退期を迎えた企業の処方箋

  • 現状に慢心して周囲の環境変化に無関心なままでいると、気づいたときには手遅れるになってしまう
  • 低迷の原因の多くは移りゆく環境の変化に対応していない点にあり、誰かの特定の個人が下した決断というよりも、情緒や感情移入に基づく「空気的判断」を積み重ねた結果として、「環境変化に対応しないこと」「変わらないこと」を集団として選択した結果である
  • 真に組織の永続的な発展を目指すためには、業績の回復と同等か、あるいはそれ以上に、組織の風土や体質を根本的に改善することにこそ考えを巡らせるべき。これは一朝一夕になし得ることでなく、目の前の事業に関する取り組みを変えるだけでなく、その前提となる思考そのものを改めなければならない
  • 細かな経験を積み重ねるうつに、以前はできなかったことがいつしかできる

この章は大手企業だけでなく、中小企業や調達・上場直後のスタートアップ、個人にも当てはまると思う。

第5章 既存企業のイノベーションに対する渇望

軌道に乗っている事業を安定的に運営することと、新たに事業を立ち上げることでは、求められるスキルセットもマインドセットも異なる

新規事業というものをどう実現するかは、明確な答えはないけど、これはその一つの解決方法だと思う。

第6章 資本市場に翻弄されないために

会社の永続的な成長にコミットする経営者と、持ち株の価値の向上を志向する投資家の間で、方向性に対する微妙なずれが生じ得る

企業の目的と手段に関する深い考察。

第7章 個として独立するための原則と心意気

  • 苦しいときでも起点の動機が強ければ、その思いが自分の背中を後押ししてくれる
  • いつの時代においても、安定を求めることができる対象は、「自分自身」にほかならない。
  • 各自が各自なりに、どこに行っても自分の力でやっていける状態をつくり、自己防衛することが、一番安定に資する

この考えかたは現代の日本人には本当に大事なものだと感じた。

最後に

著者の経験談や考えとともに、本書の中に登場する名言・引用が内容にあっており、考えを一段深くさせる。 この本はスタートアップに転職する時に、企業のおかれている状況とその中で経営者、ミッション、VCなどであるべきかの企業選びの視点の参考にもなると思う。

Railsアプリケーション構築のはじめ

Railsでアプリケーションを構築する最初の手順。

前提

開発環境の前提はこちらに記述。

l-chika.hatenablog.com

環境

手順

Rails初期化

$ mkdir {APPLICATION_DIR} && cd $_
$ bundle init
$ vim Gemfile
source "https://rubygems.org"

gem 'rails', '~> 5.0', '>= 5.0.1'

アプリケーション作成

Gemfileがコンフリクトするので上書きをする。

$ bundle exec rails new . -T -d mysql --skip-bundle --skip-turbolinks
Overwrite {APPLICATION_DIR}/Gemfile? (enter "h" for help) [Ynaqdh] Y

Gemfileの therubyracer をコメントインして、bundle install

 $ vim Gem file
# See https://github.com/rails/execjs#readme for more supported runtimes
gem 'therubyracer', platforms: :ruby
$ bundle install --path=vendor/bundle --jobs=4

DB設定

  • ※ 必要に応じて、 config/database.yml を修正
$ ./bin/rails db:create

MySQL確認

$ mysql -uroot
mysql> show databases;
+---------------------+
| Database            |
+---------------------+
| information_schema  |
| xxxxxxx_development |
| xxxxxxx_test        |
| mysql               |
| performance_schema  |
+---------------------+
5 rows in set (0.00 sec)

起動確認

$ ./bin/rails s -b 0.0.0.0

http://0.0.0.0:3000 にアクセスしてブラウザで確認。

↓が表示されればOK。

f:id:l-chika:20170123193922p:plain

ソース管理する場合は

gitignore

/vendor/bundle/ を追記。

$ vim .gitignore
...
/vendor/bundle/

関連書籍

Ruby on Rails 5 超入門

Ruby on Rails 5 超入門

参考ページ

railsコマンド(rails) - - Railsドキュメント

qiita.com

kz-engineer-scrap.hatenablog.com

「暗号技術入門 第3版 秘密の国のアリス」を読んで

既にいろんなブログでレビューがあるので今更だけど、最近読んだので自分なりの感じた点をまとめる。

暗号技術入門 第3版 秘密の国のアリス

暗号技術入門 第3版 秘密の国のアリス

読んだきっかけ

本書を読もうと思ったのはNginxやELBでのSSL関連の設定をしている時に、そういった技術体系が理解したくなった。 そこで本書の中にある「SSL/TLS セキュアな通信のために」という章があり、そこだけも読んでみようと思った。 しかし、SSL/TLSをしっかりと理解するには本書の前半にあるそれを支える技術を理解しないといけない。 ただ本書は理解しやすく、最初のきっかけを忘れて読み進める事ができた。

概要

暗号技術の全般的な知識を分かり易く解説。 アリスやボブといった人物を例にした各章の説明・クイズが非常にわかりやすい。

どんな人向け

本書には、

  • 暗号全般に興味がある人
  • 公開鍵暗号やデジタル署名など、暗号技術の仕組みを理解したいと思っている人
  • セキュリティに興味がる人

とあるが、 暗号化技術を全般を体系的に理解でき、プログラマーであれば一度は目を通してみても良いと思う良書。

以下、ザックリとメモ書き程度に。

第Ⅰ部.暗号

P13.暗号学者の道具箱

セキュリティに対する脅威 脅かされる特性 防衛のための暗号技術
盗聴 機密性 対称暗号・公開鍵暗号
改竄 正真性 一方向ハッシュ関数・メッセージ認証コード・デジタル署名
なりすまし 認証 メッセージ認証コード・デジタル署名
否認 否認不可能性 デジタル署名

それぞれの技術がどういった役割があるかを整理されており、その中身がしっかりと本書の中で説明されている。

P15.暗号とセキュリティの常識

  • 秘密の暗号アルゴリズムを使うな
  • 弱い暗号は暗号化しないよりも危険である
  • どんな暗号もいつかは解読される
  • 暗号はセキュリティのほんの一部である

これが本書の中で繰り返し言われる事で、本当に納得した。

そして、第Ⅰ部では

  • シーザー暗号から始まる暗号の歴史
  • ブロック暗号化の処理フローをわかりやすく解説

などがあり読み物としても面白く、数学の知識がなくても理解できる説明。

第Ⅱ部.認証

普段何気なく利用している 一方向ハッシュ関数

MD4,MD5SHA-1,SHA-2の説明や、SHA-3の選定プロセスは興味深かった。

そして どの一方向ハッシュ関数を使えばよいか といった結論まであり大変勉強になった。

第Ⅲ部.鍵・乱数・応用技術

  • SSL/TLS・・・Webアプリケーションを開発する人間であれば、この章はちゃんと理解しておいた方が良いと思った。
  • ビットコイン・・・簡単ではあるば、ビットコインとその暗号化技術についても触れられている。

まとめ

ざっと読んだけど、また読み返したくなる机の横にあって良いようなそんな本。

本書で紹介された

暗号の秘密とウソ

暗号の秘密とウソ

CloudWatch Logsのログファイルを監視メモ

アプリケーション・サーバーのログをCloudWatchで集約するための設定時のメモ。

基本的には以下を参考にする。

dev.classmethod.jp

AccessDeniedExceptionが発生

この際、インスタンスに設定したロールにCloudWatchポリシーを設定するのを失念した為、ログの転送がされずに、以下のエラーがログ・ファイルに出力された。

$ sudo cat /var/log/awslogs.log
2017-01-16 05:30:07,690 - cwlogs.push.publisher - WARNING - 3947 - Thread-3 - Caught exception: An error occurred (AccessDeniedException) when calling the PutLogEvents operati

・・・中略・・・

ClientError: An error occurred (AccessDeniedException) when calling the PutLogEvents operation: User: arn:aws:sts::913687097810:assumed-role/ec2_hoge/i-8aa0ff05 is not author
ized to perform: logs:PutLogEvents on resource: arn:aws:logs:ap-northeast-1:913687097810:log-group:api_/var/log/syslog:log-stream:hoge.com
2017-01-16 05:30:07,693 - cwlogs.push.publisher - WARNING - 3947 - Thread-5 - Caught exception: An error occurred (AccessDeniedException) when calling the PutLogEvents operati

CloudWatchポリシーをアタッチ

インスタンスのロールに、CloudWatchポリシーをアタッチしてログエージェントを再起動でOK。

CloudWatchLogポリシー

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "logs:DescribeLogStreams"
            ],
            "Resource": [
                "arn:aws:logs:*:*:*"
            ]
        }
    ]
}
$ sudo service awslogs restart

関連本

AWSのオススメ本。

Amazon Web Services完全ソリューションガイド

Amazon Web Services完全ソリューションガイド

screenコマンドについて

screenコマンドのメモ。

screenの説明のサイトはすごいあるけど、sshでセッションが切れてからの復帰方法について書かれているサイトが中々見つからなかったのでメモ。

手順

sshでログインしてscreen 実行。

$ screen

で、このままタイムアウトした場合に、

再度sshでログインして、screen -r をするとThere is no screen to be resumed.となってscreenにアタッチできない

$ screen -ls
There is a screen on:
    14188.pts-0.hoge-dev    (01/11/2017 03:01:17 PM)    (Attached)
1 Socket in /var/run/screen/S-foo.

$ screen -r
There is a screen on:
    14188.pts-0.hoge-dev    (01/11/2017 03:01:16 PM)    (Attached)
There is no screen to be resumed.

上記のようになったら、以前のsshでのログインプロセスをkillする

$ ps aux|grep pts|grep sshd
foo 13786  0.0  0.1 107736  1888 ?        S    14:54   0:00 sshd: foo@pts/0
foo 14920  0.0  0.1 107736  1880 ?        S    15:22   0:00 sshd: foo@pts/2
foo 14987  0.0  0.0  10460   932 pts/2    S+   15:23   0:00 grep --color=auto sshd

$ kill 13786

killをしたら、再度アタッチ

$ screen -r

これで大丈夫。

[改訂第3版]Linuxコマンドポケットリファレンス

[改訂第3版]Linuxコマンドポケットリファレンス

screenコマンドの説明

dotnsf.blog.jp

qiita.com

qiita.com

アタッチの説明

bayashi.net

Webサイト構築の構造・骨格・表層

自分なりのWebサイト構築手順のまとめ。

IAシンキング Web制作者・担当者のためのIA思考術 を参考にフローを整理し、サイトのコンセプト以降からシステム設計の手前に至るまでの手順。

Webサービス構築のきっかけについては、 こちら で。

Webサイト構築に必要なプロセス

  1. 戦略
    • サイトの目的
    • ユーザーニーズ
  2. 要求
    • 機能仕様
    • コンテンツ要求
  3. 構造
  4. 骨格
    • 情報デザイン
      • インターフェースデザイン
      • ナビゲーションデザイン
  5. 表層
    • ビジュアルデザイン

1 -> 5 は時系列な順序であり、上から下に行く事で 抽象的->具体的 となる。

ここでは、「3. 構造」以降についてをまとめてみる。

※ 戦略・ 要求については、こちら で。

サイトストラクチャ

簡単に言うとサイトマップの事。動作手順や画面遷移のフローチャート等をつくる。

そしてこの段階で以下を決める

表現方法の統一

IAシンキングでは設計での表現方法の統一としているが、自分の場合にはサイトで利用する文言統一をこの段階で決定する

ハイレベルサイトストラクチャ

IAシンキングでは「サイトを俯瞰し要点をおさえる」とし、コアコンテンツを見つけ出し、それを書き出すとある。 で、その思考フレームワークとして以下を例示。

  1. トップページとその他コンテンツ群
  2. メインメニュー類
  3. サブカテゴリー
  4. 詳細コンテンツ群

で、自分の場合をザックリと以下に。

  1. ホーム:最新記事
  2. グローバル:部品、記事
  3. 部品一覧、記事検索
  4. 部品詳細

画面設計

IAシンキングでは「画面設計」とは、「ラベル設計」「サイトストラクチャ設計」「ナビゲーション設計」の集大成とある。 そして、次の3つを抑える必要がある 1. 画面内のエリア定義(レイアウト) 2. 画面前後のフロー(ナビゲーション) 3. 画面内の機能(アクション)

自分のサイトの特性から、あらかじめあるページタイプ、レイアウトパターンをイメージして細部をつめてみる。 自分の場合には、Free Responsive Mobile Website Templates Designs - w3layouts.com から近いカテゴリーを見つけて、設計をしてみる

ワイヤーフレーム

上記から近いイメージのページをみつけたら、 Wirify ブックマークレットを利用してワイヤーフレームを表示し、それを元に自分でCacooやKyenoteを利用してワイヤーフレームを作成する。

これ以降は?

ここまでがコンセプトを決めてからの画面イメージを決めるまでのざっとした概要。

ここからシステム設計(URL、DB、etc)に行程を進めていく。

IAシンキング Web制作者・担当者のためのIA思考術

IAシンキング Web制作者・担当者のためのIA思考術

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

w3layouts.com

www.wirify.com

cacoo.com