おぴよの気まぐれ日記

おぴよの気まぐれ日記

岡山やプログラミング、ファッションのこと、子育てや人生、生き方についての備忘録。

Ruby on Rails チュートリアルで30歳までに人生を変える(第6章)

こんにちは。opiyoです。

今回は、第6章をやっていきます。

第6章はユーザーのモデルを作っていきます。

railsチュートリアル6章の学んだこと

$ rails db:rollback
$ rails c --sandbox
Running via Spring preloader in process 3062
Loading development environment in sandbox (Rails 5.0.0.1)
Any modifications you make will be rolled back on exit
  • モデルだけのテスト実行
$ rails test:models
  1/1: [============================================================================================================================================================] 100% Time: 00:00:00, Time: 00:00:00

Finished in 0.03454s
1 tests, 1 assertions, 0 failures, 0 errors, 0 skips
  • オブジェクトが有効かどうかはvalid?メソッドを使う
  • ハッシュ化とは元に戻せない不可逆なデータに処理する

  • !!でそのオブジェクトが対応する論理値オブジェクトに変換できる

  • モデルの作成方法

$ rails generate model User name:string email:string
      invoke  active_record
      create    db/migrate/20160523010738_create_users.rb
      create    app/models/user.rb
      invoke    test_unit
      create      test/models/user_test.rb
      create      test/fixtures/users.yml
  • コントローラー名は複数形
  • モデル名は単数形
  • マイグレーションファイル
    • データベースに与える変更を定義したもの
    • rails db:migrateで反映する
    • SQLiteの場合はdevelopment.sqlite3 というファイルが出来上がり、これが実体になる
    • 元に戻す場合は rails db:rollback
  • update_attributesメソッドは属性のハッシュを受け取り、成功時には更新と保存を続けて同時に行います (保存に成功した場合はtrueを返します)。 ただし、検証に1つでも失敗すると、 update_attributesの呼び出しは失敗します。
  • 特定の属性のみを更新したい場合は、次のようにupdate_attributeを使います。このupdate_attributeには、検証を回避するといった効果もあります。
> u.update_attribute(name: "El Duderino") # この書き方ではダメ
ArgumentError: wrong number of arguments (given 1, expected 2)

>> user.update_attribute(:name, "El Duderino") # カンマが区切ってキーと値で渡す
=> true
>> user.name
=> "El Duderino"

railsチュートリアル6章の演習解説

6.1.1 演習 データベースの移行

6.1.1.1

<問題>Railsはdb/ディレクトリの中にあるschema.rbというファイルを使っています。これはデータベースの構造 (スキーマ (schema) と呼びます) を追跡するために使われます。さて、あなたの環境にあるdb/schema.rbの内容を調べ、その内容とマイグレーションファイル (リスト 6.2) の内容を比べてみてください。

<回答>

#db/schema.rb
ActiveRecord::Schema.define(version: 20170630074441) do

  create_table "users", force: :cascade do |t|
    t.string   "name"
    t.string   "email"
    t.datetime "created_at",      null: false
    t.datetime "updated_at",      null: false
  end
end
# db/migrate/20170629005430_create_users.rb
class CreateUsers < ActiveRecord::Migration[5.0]
  def change
    create_table :users do |t|
      t.string :name
      t.string :email

      t.timestamps
    end
  end
end

6.1.1.2

<問題>ほぼすべてのマイグレーションは、元に戻すことが可能です (少なくとも本チュートリアルにおいてはすべてのマイグレーションを元に戻すことができます)。元に戻すことを「ロールバック (rollback)と呼び、Railsではdb:rollbackというコマンドで実現できます。 $ rails db:rollback 上のコマンドを実行後、db/schema.rbの内容を調べてみて、ロールバックが成功したかどうか確認してみてください (コラム 3.1ではマイグレーションに関する他のテクニックもまとめているので、参考にしてみてください)。 上のコマンドでは、データベースからusersテーブルを削除するためにdrop_tableコマンドを内部で呼び出しています。 これがうまくいくのは、drop_tableとcreate_tableがそれぞれ対応していることをchangeメソッドが知っているからです。この対応関係を知っているため、ロールバック用の逆方向のマイグレーションを簡単に実現することができるのです。なお、あるカラムを削除するような不可逆なマイグレーションの場合は、changeメソッドの代わりに、upとdownのメソッドを別々に定義する必要があります。 詳細については、Railsガイドの「Active Record マイグレーション」を参照してください。

<回答>

ActiveRecord::Schema.define(version: 0) do

end

6.1.1.3

<問題>もう一度rails db:migrateコマンドを実行し、db/schema.rbの内容が元に戻ったことを確認してください。

<回答>

ActiveRecord::Schema.define(version: 20170630074441) do

  create_table "users", force: :cascade do |t|
    t.string   "name"
    t.string   "email"
    t.datetime "created_at",      null: false
    t.datetime "updated_at",      null: false
  end
end

6.1.2 演習 modelファイル

6.1.2.1

<問題>Railsコンソールを開き、User.newでUserクラスのオブジェクトが生成されること、そしてそのオブジェクトがApplicationRecordを継承していることを確認してみてください (ヒント: 4.4.4で紹介したテクニックを使ってみてください)。

<回答>

> u = User.new
> u.class.superclass
=> ApplicationRecord(abstract)

6.1.2.2

<問題>同様にして、ApplicationRecordがActiveRecord::Baseを継承していることについて確認してみてください。

<回答>

> u.class.superclass.superclass
=> ActiveRecord::Base

6.1.3 演習 ユーザーオブジェクトを作成する

6.1.3.1

<問題>user.nameとuser.emailが、どちらもStringクラスのインスタンスであることを確認してみてください。

<回答>

* user = User.new(name: "Michael Hartl", email: "mhartl@example.com")
=> #<User id: nil, name: "Michael Hartl", email: "mhartl@example.com", created_at: nil, updated_at: nil, password_digest: nil>
irb(main):019:0> user.name.class
=> String
irb(main):020:0> user.email.class
=> String

6.1.3.2

<問題>created_atとupdated_atは、どのクラスのインスタンスでしょうか?

<回答>

* user.created_at.class
=> NilClass
> user.updated_at.class
=> NilClass

6.1.4 演習 ユーザーオブジェクトを検索する

6.1.4.1

<問題>nameを使ってユーザーオブジェクトを検索してみてください。また、 find_by_nameメソッドが使えることも確認してみてください (古いRailsアプリケーションでは、古いタイプのfind_byをよく見かけることでしょう)。

<回答>

* User.find_by(name: "Michael Hartl")
  User Load (0.2ms)  SELECT  "users".* FROM "users" WHERE "users"."name" = ? LIMIT ?  [["name", "Michael Hartl"], ["LIMIT", 1]]
=> #<User id: 1, name: "Michael Hartl", email: "mhartl@example.com", created_at: "2017-08-14 00:50:04", updated_at: "2017-08-14 00:50:04", password_digest: "$2a$10$vp5fiCtIdDwU/AdskPGeKeZ35UdjtkZbPWnV3i7g0Rq...">
irb(main):030:0> User.find_by_name("Michael Hartl")
  User Load (0.1ms)  SELECT  "users".* FROM "users" WHERE "users"."name" = ? LIMIT ?  [["name", "Michael Hartl"], ["LIMIT", 1]]
=> #<User id: 1, name: "Michael Hartl", email: "mhartl@example.com", created_at: "2017-08-14 00:50:04", updated_at: "2017-08-14 00:50:04", password_digest: "$2a$10$vp5fiCtIdDwU/AdskPGeKeZ35UdjtkZbPWnV3i7g0Rq...">

6.1.4.2

<問題>実用的な目的のため、User.allはまるで配列のように扱うことができますが、実際には配列ではありません。 User.allで生成されるオブジェクトを調べ、ArrayクラスではなくUser::ActiveRecord_Relationクラスであることを確認してみてください。

<回答>

* User.all.class
=> User::ActiveRecord_Relation

6.1.4.3

<問題>User.allに対してlengthメソッドを呼び出すと、その長さを求められることを確認してみてください (4.2.3)。Rubyの性質として、そのクラスを詳しく知らなくてもなんとなくオブジェクトをどう扱えば良いかわかる、という性質があります。これをダックタイピング (duck typing) と呼び、よく次のような格言で言い表されています「もしアヒルのような容姿で、アヒルのように鳴くのであれば、それはもうアヒルだろう」。(訳注: そういえばRubyKaigi 2016の基調講演で、Ruby作者のMatzがダックタイピングについて説明していました。2〜3分の短くて分かりやすい説明なので、ぜひ視聴してみてください!)

<回答>

 User.all.length
  User Load (0.5ms)  SELECT "users".* FROM "users"
=> 2

6.1.5 演習 ユーザーオブジェクトを更新する

6.1.5.1

<問題>userオブジェクトへの代入を使ってname属性を使って更新し、saveで保存してみてください。

<回答>

> User.first
  User Load (0.1ms)  SELECT  "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT ?  [["LIMIT", 1]]
=> #<User id: 1, name: "Michael Hartl", email: "mhartl@example.com", created_at: "2017-08-14 00:50:04", updated_at: "2017-08-14 00:50:04">
irb(main):002:0> u = User.first
  User Load (0.1ms)  SELECT  "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT ?  [["LIMIT", 1]]
=> #<User id: 1, name: "Michael Hartl", email: "mhartl@example.com", created_at: "2017-08-14 00:50:04", updated_at: "2017-08-14 00:50:04">
irb(main):003:0> u.name
=> "Michael Hartl"
irb(main):004:0> u.name = "Haku"
=> "Haku"
irb(main):005:0> u.save
   (0.1ms)  begin transaction
  User Exists (0.2ms)  SELECT  1 AS one FROM "users" WHERE LOWER("users"."email") = LOWER(?) AND ("users"."id" != ?) LIMIT ?  [["email", "mhartl@example.com"], ["id", 1], ["LIMIT", 1]]
  SQL (0.3ms)  UPDATE "users" SET "name" = ?, "updated_at" = ? WHERE "users"."id" = ?  [["name", "Haku"], ["updated_at", 2017-08-14 01:06:07 UTC], ["id", 1]]
   (1.3ms)  commit transaction
=> true

6.1.5.2

<問題>今度はupdate_attributesを使って、email属性を更新および保存してみてください。

<回答>

> u.update_attributes(email: "haku@example.com")
   (0.1ms)  begin transaction
  User Exists (0.2ms)  SELECT  1 AS one FROM "users" WHERE LOWER("users"."email") = LOWER(?) AND ("users"."id" != ?) LIMIT ?  [["email", "haku@example.com"], ["id", 1], ["LIMIT", 1]]
  SQL (0.3ms)  UPDATE "users" SET "email" = ?, "updated_at" = ? WHERE "users"."id" = ?  [["email", "haku@example.com"], ["updated_at", 2017-08-14 01:10:15 UTC], ["id", 1]]
   (1.6ms)  commit transaction
=> true

6.1.5.3

<問題>同様にして、マジックカラムであるcreated_atも直接更新できることを確認してみてください。ヒント: 更新するときは「1.year.ago」を使うと便利です。これはRails流の時間指定の1つで、現在の時刻から1年前の時間を算出してくれます。

<回答>

* u.update_attribute(:created_at, 1.year.ago)
   (0.1ms)  begin transaction
  SQL (0.3ms)  UPDATE "users" SET "created_at" = ?, "updated_at" = ? WHERE "users"."id" = ?  [["created_at", 2016-08-14 01:14:57 UTC], ["updated_at", 2017-08-14 01:14:57 UTC], ["id", 1]]
   (1.6ms)  commit transaction
=> true

6.2.1 演習 有効性を検証する

6.2.1.1

<問題>コンソールから、新しく生成したuserオブジェクトが有効 (valid) であることを確認してみましょう。

<回答>

* user = User.new(name: "Example User", email: "user@example.com")
=> #<User id: nil, name: "Example User", email: "user@example.com", created_at: nil, updated_at: nil>
irb(main):009:0> user.valid?
  User Exists (0.2ms)  SELECT  1 AS one FROM "users" WHERE LOWER("users"."email") = LOWER(?) LIMIT ?  [["email", "user@example.com"], ["LIMIT", 1]]
=> true

6.2.1.2

<問題>6.1.3で生成したuserオブジェクトも有効であるかどうか、確認してみましょう。

<回答>

* user = User.new(name: "Michael Hartl", email: "mhartl@example.com")
=> #<User id: nil, name: "Michael Hartl", email: "mhartl@example.com", created_at: nil, updated_at: nil>
irb(main):013:0> user.valid?
  User Exists (0.2ms)  SELECT  1 AS one FROM "users" WHERE LOWER("users"."email") = LOWER(?) LIMIT ?  [["email", "mhartl@example.com"], ["LIMIT", 1]]
=> true

6.2.2 演習 存在性を検証する

6.2.2.1

<問題>新しいユーザーuを作成し、作成した時点では有効ではない (invalid) ことを確認してください。なぜ有効ではないのでしょうか? エラーメッセージを確認してみましょう。

<回答>

* u = User.new
=> #<User id: nil, name: nil, email: nil, created_at: nil, updated_at: nil>
irb(main):008:0> u.invalid?
  User Exists (0.2ms)  SELECT  1 AS one FROM "users" WHERE "users"."email" IS NULL LIMIT ?  [["LIMIT", 1]]
=> true
irb(main):009:0> u.valid?
  User Exists (0.2ms)  SELECT  1 AS one FROM "users" WHERE "users"."email" IS NULL LIMIT ?  [["LIMIT", 1]]
=> false
irb(main):010:0> u.errors.full_messages
=> ["Name can't be blank", "Email can't be blank", "Email is invalid"]

6.2.2.2

<問題>u.errors.messagesを実行すると、ハッシュ形式でエラーが取得できることを確認してください。emailに関するエラー情報だけを取得したい場合、どうやって取得すれば良いでしょうか?

<回答>

> errors = u.errors.messages # `errors.messages`でハッシュになる
=> {:name=>["can't be blank"], :email=>["can't be blank", "is invalid"]}
irb(main):023:0* errors[:email]
=> ["can't be blank", "is invalid"]

6.2.3 演習 長さを検証する

6.2.3.1

<問題>長すぎるnameとemail属性を持ったuserオブジェクトを生成し、有効でないことを確認してみましょう。

<回答>

* u = User.new
=> #<User id: nil, name: nil, email: nil, created_at: nil, updated_at: nil>
irb(main):046:0> u.name = "a" * 51
=> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
irb(main):047:0> u.name.size
=> 51
irb(main):048:0> u.email = "a" * 255 + "@co.jp"
=> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa@co.jp"
irb(main):049:0> u.email.size
=> 261
irb(main):050:0> u.valid?
  User Exists (0.2ms)  SELECT  1 AS one FROM "users" WHERE LOWER("users"."email") = LOWER(?) LIMIT ?  [["email", "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa@co.jp"], ["LIMIT", 1]]
=> false
irb(main):051:0> u.error
u.error_on_ignored_order_or_limit u.errors

irb(main):051:0> u.error
u.error_on_ignored_order_or_limit u.errors

6.2.3.2

<問題>長さに関するバリデーションが失敗した時、どんなエラーメッセージが生成されるでしょうか? 確認してみてください。

<回答>

> u.errors.full_messages
=> ["Name is too long (maximum is 50 characters)", "Email is too long (maximum is 255 characters)"]

6.2.4 演習 フォーマットを検証する

6.2.4.1

<問題>リスト 6.18にある有効なメールアドレスのリストと、リスト 6.19にある無効なメールアドレスのリストをRubularのYour test string:に転記してみてください。その後、リスト 6.21の正規表現をYour regular expression:に転記して、有効なメールアドレスのみがすべてマッチし、無効なメールアドレスはすべてマッチしないことを確認してみましょう。

<回答> f:id:opiyotan:20170815131537p:plain

6.2.4.2

<問題>先ほど触れたように、リスト 6.21のメールアドレスチェックする正規表現は、foo@bar..comのようにドットが連続した無効なメールアドレスを許容してしまいます。まずは、このメールアドレスをリスト 6.19の無効なメールアドレスリストに追加し、これによってテストが失敗することを確認してください。次に、リスト 6.23で示した、少し複雑な正規表現を使ってこのテストがパスすることを確認してください。

<回答>

# app/models/user.rb
 class User < ApplicationRecord
  validates :name, presence: true, length: { maximum: 50 }
  VALID_EMAIL_REGEX = /\A[\w+\-.]+@[a-z\d\-]+(\.[a-z\d\-]+)*\.[a-z]+\z/i
  validates :email, presence:   true, length: { maximum: 255 },
                    format:     { with: VALID_EMAIL_REGEX }
end
# test/models/user_test.rb
  test "email validation should reject invalid addresses" do
    invalid_addresses = %w[user@example,com user_at_foo.org user.name@example.
                           foo@bar_baz.com foo@bar+baz.com foo@bar..com]
    invalid_addresses.each do |invalid_address|
      @user.email = invalid_address
      assert_not @user.valid?, "#{invalid_address.inspect} should be invalid"
    end
  end

6.2.4.3

<問題>foo@bar..comをRubularのメールアドレスのリストに追加し、リスト 6.23の正規表現をRubularで使ってみてください。有効なメールアドレスのみがすべてマッチし、無効なメールアドレスはすべてマッチしないことを確認してみましょう。

<回答> f:id:opiyotan:20170815132436p:plain

6.2.5 演習 一意性を検証する

6.2.5.1

<問題> リスト 6.33を参考に、メールアドレスを小文字にするテストをリスト 6.32に追加してみましょう。ちなみに追加するテストコードでは、データベースの値に合わせて更新するreloadメソッドと、値が一致しているかどうか確認するassert_equalメソッドを使っています。リスト 6.33のテストがうまく動いているか確認するためにも、before_saveの行をコメントアウトして redになることを、また、コメントアウトを解除すると greenになることを確認してみましょう。

<回答> 問題なし

# before_saveをコメントアウトすると大文字、小文字が合致せずエラーになる
$ rails test
Running via Spring preloader in process 5880
Started with run options --seed 39690

 FAIL["test_email_addresses_should_be_saved_as_lower-case", UserTest, 1.0127649949990882]
 test_email_addresses_should_be_saved_as_lower-case#UserTest (1.01s)
        Expected: "foo@example.com"
          Actual: "Foo@ExAMPle.CoM"

6.2.5.2

<問題>テストスイートの実行結果を確認しながら、before_saveコールバックをemail.downcase!に書き換えてみましょう。ヒント: メソッドの末尾に!を付け足すことにより、email属性を直接変更できるようになります (リスト 6.34)。

<回答>

before_save { self.email = email.downcase }
↓
before_save { email.downcase! }
  • 気になること - self.email.downcase! じゃなくていいの? emailをはどう参照されるのだろうか。 selfがあれば、そのオブジェクト自身ってわかる気がするけどそれを勝手にやってくれるってことなのかな...

6.3.2 演習 ユーザーがセキュアなパスワードを持っている

6.3.2.1

<問題>この時点では、userオブジェクトに有効な名前とメールアドレスを与えても、valid?で失敗してしまうことを確認してみてください。

<回答>

* u = User.new
=> #<User id: nil, name: nil, email: nil, created_at: nil, updated_at: nil, password_digest: nil>
irb(main):016:0> u.name = "Haku"
=> "Haku"
irb(main):017:0> u.email = "haku@co.jp"
=> "haku@co.jp"
irb(main):018:0> u.valid?
  User Exists (0.2ms)  SELECT  1 AS one FROM "users" WHERE LOWER("users"."email") = LOWER(?) LIMIT ?  [["email", "haku@co.jp"], ["LIMIT", 1]]
=> false

6.3.2.2

<問題> なぜ失敗してしまうのでしょうか? エラーメッセージを確認してみてください。

<回答>

irb(main):019:0> u.errors.full_messages
=> ["Password can't be blank"]

6.3.3 演習 パスワードの最小文字数

6.3.3.1

<問題>有効な名前とメールアドレスでも、パスワードが短すぎるとuserオブジェクトが有効にならないことを確認してみましょう。

<回答>

* u = User.new
=> #<User id: nil, name: nil, email: nil, created_at: nil, updated_at: nil, password_digest: nil>
irb(main):007:0> u.name = "Haku"
=> "Haku"
irb(main):008:0> u.email = "haku@co.jp"
=> "haku@co.jp"
irb(main):009:0> u.password = u.password_confirmation = "haku"
=> "haku"
irb(main):010:0> u.valid?
  User Exists (0.2ms)  SELECT  1 AS one FROM "users" WHERE LOWER("users"."email") = LOWER(?) LIMIT ?  [["email", "haku@co.jp"], ["LIMIT", 1]]
=> false

6.3.3.2

<問題> 上で失敗した時、どんなエラーメッセージになるでしょうか? 確認してみましょう。

<回答>

> u.errors.full_messages
=> ["Password is too short (minimum is 6 characters)"]

6.3.4 演習 ユーザーの作成と認証

6.3.4.1

<問題>コンソールを一度再起動して (userオブジェクトを消去して)、このセクションで作ったuserオブジェクトを検索してみてください。

<回答>

$ rails c
Running via Spring preloader in process 6789
Loading development environment (Rails 5.0.0.1)
No entry for terminal type "ake/version";
using dumb terminal settings.
irb(main):001:0> User.find_by(email: "mhartl@example.com")
  User Load (0.2ms)  SELECT  "users".* FROM "users" WHERE "users"."email" = ? LIMIT ?  [["email", "mhartl@example.com"], ["LIMIT", 1]]
=> #<User id: 1, name: "Michael Hartl", email: "mhartl@example.com", created_at: "2017-08-15 06:49:16", updated_at: "2017-08-15 06:49:16", password_digest: "$2a$10$ZDicArmstR/XhkV.IKJVu.hMWDn5oh.P3pilUSBlJOi...">

6.3.4.2

<問題>オブジェクトが検索できたら、名前を新しい文字列に置き換え、saveメソッドで更新してみてください。うまくいきませんね...、なぜうまくいかなかったのでしょうか?

<回答>

> user = User.find_by(email: "mhartl@example.com")
  User Load (0.2ms)  SELECT  "users".* FROM "users" WHERE "users"."email" = ? LIMIT ?  [["email", "mhartl@example.com"], ["LIMIT", 1]]
=> #<User id: 1, name: "Michael Hartl", email: "mhartl@example.com", created_at: "2017-08-15 06:49:16", updated_at: "2017-08-15 06:49:16", password_digest: "$2a$10$ZDicArmstR/XhkV.IKJVu.hMWDn5oh.P3pilUSBlJOi...">
irb(main):003:0> user.name = "Haku"
=> "Haku"
irb(main):004:0> user.save
   (0.2ms)  begin transaction
  User Exists (0.2ms)  SELECT  1 AS one FROM "users" WHERE LOWER("users"."email") = LOWER(?) AND ("users"."id" != ?) LIMIT ?  [["email", "mhartl@example.com"], ["id", 1], ["LIMIT", 1]]
   (0.1ms)  rollback transaction
=> false
irb(main):005:0> user.errors.full_messages
=> ["Password can't be blank", "Password is too short (minimum is 6 characters)"] # 

nameだけ変更してsaveしているが、passwordも保存することを要求されるので「password」が無いよってエラーになる。 nameだけ明示的に変更する場合は、6.3.4.3の方法を利用する。

6.3.4.3

<問題>今度は6.1.5で紹介したテクニックを使って、userの名前を更新してみてください。

<回答>

* user.update_attribute(:name, "Haku")
   (0.1ms)  begin transaction
  SQL (0.4ms)  UPDATE "users" SET "name" = ?, "updated_at" = ? WHERE "users"."id" = ?  [["name", "Haku"], ["updated_at", 2017-08-15 06:59:37 UTC], ["id", 1]]
   (1.9ms)  commit transaction
=> true
irb(main):010:0> user.name
=> "Haku"

会社での目標じゃなくて自分の目標を立てた方が人生は変わる

8月も1/3が終わり8末になると期が変わるって会社も多いのではないだろうか。

期が変わるってなると面談があったり色々と変化があるだろう。

私の会社も8末で期が変わるので色々面談したり目標に対する成果をまとめた資料作ったりが発生するのだが非常に面倒だ。

この目標とそれの達成について今日は思ったことを書こうと思う。


今期の振り返りとして

やったー万歳! 目標達成だー!

ってなったのだけど本当に凄いことだし良い事だと思う。

来期の目標を立てるときは、今期の目標と結果に対して会社全体の目標がまず決まる。

それを達成するためにチームの目標があり、個人の目標だある。

会社で立てる目標ってのは会社の目標を叶えるための目標であって実は自分の目標に直結しないこともあると思う。

この会社で生きるための力を付けることがゴールだから当たり前っちゃ当たり前なのかな。



評価制度が変わるよって話もあったのだけどどうやら組織が大きくなってきたから昔と同じように評価することは難しいって事らしい。

ここ数年人数の増減は無いし大きくなった感覚は無いのだが今までの評価については何だったのだろうか。まーそれはおいておく。ここは変わらないけど、ここが変わる。それによってこんな風になるのよ。素敵でしょ。って感じなのだが皆が知りたいのは結局「どんだけ上がるんだ」って話。これだけ。


今まではどうなったらどんだけ上がるってのが無かったから、それが明確になるなら良いなとは思う。

僕が会社から期待されている役割は具体的にこうだ!ってのがふんわりしてたからそれが具体的になるのはよいことだ。

だけどこれも結局、会社のための力であって外に出たときに通用するのかってのは全く別問題だ。



ここ数記事の中でも同じこと書いているが大事な事だから言うけど40年続く会社は3社らしい。

つまり一生同じ会社で働くってのは今の時代、もー不可能なのだ。

だからこそ何処行っても通用する力を若いうちにつけておく必要が絶対にある。

だから会社がどうなって欲しいかという視点だけじゃなく自分がどうなりたいのか。世の中はどんな人が必要とされているのかをしっかり確認することは絶対に大事だ!

最後に

目標の達成は大事。

会社と自分が重なっている人は幸せだ。

だけどそんな人ほとんどいないはず。

だからこそ自分はどうしたいのかっていう目標を自分のために立てよう。

そうすればきっと人生変わるはずだ。

人生に可能性なんて存在しない。あるのは目の前の現実だけ

僕は今日新幹線の中でこれを書いている。

周りにはスーツの人もいっぱいて、お酒飲んだりスマホでゲームしたりPC開いて仕事したりしている。


最近本当にこれからの人生について色々考えるのですが僕の周りにいる人達に悩みは無いのだろうか?


サラリーマンの平均年収は400~500万

独り身であれば楽勝で生活できる額でしょうが、家族がいる人、今後結婚する人にとっては、これだけでは生きていけない数字です。


皆どうやって生きているんだ?



うちもそうだが僕の周りは専業主婦家族ばかり。

確かにじいじ、ばあばと過ごしている人も多いし都会に比べたら地方なので色々安いのかもしれない。

でも、その安さも家賃くらいなもので生活していくコストは変わらない

車無いと生活できないし田舎は田舎で金がかかる。


僕は28歳。結婚してるし子供も二人いる。

どこにでもあるような普通の家族だが子供たちが育っていくことを考えたら色々考えておかなければ人生詰むだろう。


当たり前が当たり前じゃない時代にきっとなるし、もー既になっているのだろう。

この事実に気づけてない人はきっと多いだろうが、僕は知れた。

だからこそ手遅れになる前に、30歳になる前に将来に備えておくためには何かを変えなければならない。


そんな中流れてきた目に留まった記事の中にスゲー良いことが書いてあって思わず呟いてしまいました。


もーこの文章のままなのですが、僕は今まで何をしてきたんだと。

行動はしている。人より高い意識を持って日々情報を集めている。そして行動している。

だけど大きな何かをやり忘れている。何かのステップを飛んでしまっている。


そーそれは夢を叶える為の行動だ。

想いなんて誰でも持てる。夢だって語れる。だけどそれを実現する行動が伴っていなければ信用なんて出来ない。

これが吹っ飛んでるから僕は前に進めないのだ。

最後に

これはついさっきまでの僕ですが自分の人生に可能性なんて無いので辞めましょう。

あるのは目の前の現実だけ。

この現実を変えるに、どうなりたいのかを考え具体的なアクションに落とし込みそれを今やるだけです。

手遅れ何てことは絶対にないはず。

だから、動き出そう。手を動かそう。足を動かそう。

いつだって、誰だって人生は変えれるはずだ!

仕事に楽しさを求めてはいけないのだろうか

仕事が楽しくて楽しくてしょうがないんだよな~


僕の周りにはこんな奴はいない。

最近色々な人と話すきっかけがあって本当に良い刺激を頂いているしネットの世界では楽しそうに生きている人がいっぱいから、この感覚が全くないってのは嘘になるだろうが。

だが、僕の周りでは中々この境地に行っている人は少ないなと感じている。


何故だろうか。何故こんな差が出るのだろうか。

好きなことをして生きるとは

例えば僕は日本で、いや世界でも有名な文化服装学院というアパレル専門学校に行っていた。

間違いなく日本で服が好きな人達が集まっている場所だ。僕はここに行ったことを最初悔やんだ。これでもかと自分の世界を表現できる素晴らしい人たちの中で何となく好きで入った僕なんかが入れる場所じゃないと思ったからだ。

間違いなく服にかける熱量は凄い。間違いない。夢を見て勉強し社会に出ていく。

だが、卒業して約7年。アパレル業界で働いている人はどのくらいの人だろうか。

服を作りたいと思い学んだ2・3年間の先の就職先は販売員ってのがほとんどだ。


他の例を言うならば日常からプログラムを書くのが好きなプログラマーの方も仕事でプログラムを書けても全て思うように書けるわけではない。色々な制約やビジネスとの掛け合い、自分のポジションもある。プログラムを書くことが好きで選んだ仕事、プログラムを書けている。なのに楽しいとは決して言えない。そんなもんだ。

好きなことをして生きるって大変

好きなことをして生きていくってのが一つこれからのテーマだと思うのだけど、好きなことをして生きるってのは中々難しい。

前にもこのようなテーマで記事を書いたし上で書いた通りだが、好きな事、特殊な事ほどそこで勝負してくるライバル達も熱狂的なのである。道は狭くゴールに行ける人はある程度決まっている。


じゃーどうするのか。仕事は仕事と諦めることしかできないのか。

それもそれで一つだと思うが一日の半分以上が仕事をしなければならないことを考えると仕事を楽しめるかどうかで人生は変わってくるだろう。

そう思うと仕事って楽しいと思えるべきだが何が楽しいのかもはや分からなくなっていると人は多いと思う。もちろん僕もだ。



僕の周りを見渡した時に決して仕事が楽しいってわけじゃないのだが生きることを楽しんでいる人達はいる。

その人たちと仕事を楽しんでいる人との共通点を探してみると僕は「お金」に辿り着いた。

そこを一つ軸にしてこれからの人生考えると変わった生き方ができるのでは無いかと思っている。

最後に

そもそも「人間」として生き続けるってこと自体が仕事なのだ。 まー知っている人はビビビッとくるフレーズだろう。 「人間」という仕事なのだ。生きるってことすらも仕事なのだ。

好きなことで生きることは大変だが、お金を稼ぐってことも大変だ。

うーん生きるって大変だ。

この当たり前の日常こそが幸せなのだろう

先週末は久しぶりに家族でがっつり遊んだ気がする。


土曜日は僕の住んでいる場所で一番大きな祭りがあり、花火もいっぱいあがった。

同じ地域に住んでいる人達が同じ場所に集まり同じ空を見上げ花火を見る。

子供たちで来ている人もいるし、カップルもいる、家族もいれば、じいじばあばもいる。

みんな過ごす毎日は違うし何を考えているのか何を思っているのか普段何をしているのか何てお互い知らない。

だけど、花火を見ているその時間だけは、同じ気持ち同じ思いで同じ時間を過ごす。


やはりこういう時間ってのはとても素敵だなと思った。



日曜日は家族で地域のプールだ。

ウォータースライダーや、流行りのナイトプールみたいなオシャレさや水着のねーちゃんはいないが、子供たち浅いプールでバナナ鬼。深いプールで泳ぐ 練習。家族で同じ時間を過ごせばそれなりに面白い。

それに、なんと家族4人で300円だ! 田舎万歳である。



何か面白いことをしたでも、特別なことをしたでもない。当たり前の日常を当たり前のように過ごしただけなのだが家族と過ごす時間ってのは良いものだ。


で、まーここからが本題なのだがこの時間を更に有意義に質を高めてくれるものがある。

分かるだろうか。


.
.
.
.

そーお金だ。


なんじゃそりゃって思うかもしれないが、家族がいるからこそ思うことは正直世の中金だ。


お金があればこの思い出にの質を更にいくらでもアップさせることができる。

地域のプールじゃなくて沖縄に行った方が絶対面白い。そんなことは当たり前である。


じゃーどうやってお金を稼ぐのかって話なのだが、最近少し分かってきた気がする。

本当に色々な仕組みがある。それを知れたことは本当に良かった。


後は、そこに自分がコミットできるのか。突き抜けれるのか。そこだけかなと。

最後に

最近色々あった。今もめちゃくちゃ悩んでいる最中だ。

何が正解か何て全く分からないけど一つ思ったことは、家族って良いもんだ。

だから、この軸からは絶対に外れてはいけない。僕はそうやって生きていこう。

28歳になった今日、僕は人生詰んだことを発表します

28年前の朝、僕は生まれた。

今日まで28年という長い長い年月を過ごしてきた。

だけど、今僕は人生の帰路に立たされている。

そー気づいてしまったのだよ。この世のからくりに。


僕のこれまでの人生については改めて自己紹介として書こうと思うのだが、一言で僕の人生を表現するならば「逃げ」。

ただただ逃げてきた人生だった。


その結果、今日僕は改めて感じた。


「人生詰んだ」

2020年には年収400万以下が6割 ?

危機感だけは凄く感じていてざっと洗い出しただけでも、こんな感じだろうか

  • 40年続く会社は3社?だっけな
  • 大企業があの状態
  • 2020年には年収400万以下が6割?
  • 既に中国のエンジニアの方が高給取り
  • 会社じゃなく個人が活躍する時代
  • 昇給ってあるようで無いって気づいた
  • 一歩外出たら僕は何が出来るんだ? ⇒ 何もない
  • valuやshowroomなど個人が活躍する時代
  • 技術の発展で職を失う

このまま生きていたら、どう考えても子供が大学行くとか不可能。共働きが当たり前。残業稼ぐようなスタイルもどんどん減るだろう。僕が今やっているようなSEだって良く言えばエンジニアと営業の架け橋。なんて言うけど要らないよね。開発と営業で仕事は回る。


みたいなことを色々考えると家族ある人間からすると、あれっ結構やばいなと思うわけですよ。

やれば出来るは最高のご褒美

僕が小さい頃から親に言われ続けてきた魔法の言葉「やれば出来る」。これは絶対に使ってはいけない。


だってやれば出来ると思ってしまうからである。

「やれば」出来るんだよ。だけどこれは「やったら」出来ない事が分かってしまうから結果的に何もやらない人間を生み出してしまう。

僕の場合は先ず受験から逃げた。本当は行きたい高校があったにも関わらず本番に弱いという理由で指定校推薦を選択した。

大学もそうだ。受験勉強が嫌だから専門学校を選んだ。

これは本当にやりたい事じゃないと言って日々の勉強から逃げた。

言葉が上手く表現できないからブログを書くことから逃げた。

全て「やれば出来る」って知らぬ知らぬ間に自分に言い聞かせている。やったら出来ないを知りたくないから逃げる。

最後に

もー若くない。

Twitterを見てみよう。

ネットの世界をのぞいてみよう。

そして東京へ行ってみよう。

自分より若い人達が、活躍していることから目を離してはいけない。

自分より若い人達が、頑張っていることから目を離してはいけない。


今この一瞬、一瞬この地球上にいる誰かが同じことを考えていて歩きだしたなら、僕は走らないといけない。

そうしないとどんどんどんどん離されてしまう。

自分より若い人たちは、既にもーとんでもなく遠くにいる。

それを見ているだけじゃなくて一歩一歩踏み出そう。

そうすれば今くすぶっている人達よりかは一歩前に出れる。そうやって毎日を刻んでいこう。


人生は長いようであっという間。

まだ28歳ではなく、もー28歳。

いつでも、どんな時も人生を変えることは出来るって心から思ってる。

だけどその道は年を重ねるごとに確実に狭くなっていく。


だから今、今動きだそう。

人生を変えるには目標を叶える行動する「時間」を確保し、その行動を加速させる「環境」に行く。

そして最後まで「やりきる」こと。

やりきった先に何があるのかを想像すれば、きっと頑張れる。

今日はそんな感じ。頑張ろう自分。もう一回今日から頑張ろう。何度だって挑戦できるんだから。



誕生日おめでとう

Ruby on Rails チュートリアルで30歳までに人生を変える(第5章)

こんにちは。opiyoです。

今回は、第5章をやっていきます。

第5章はレイアウト。つまり見た目の部分をメインにやっていきます。

では、早速始めてみたいと思います。

f:id:opiyotan:20170626134807p:plain

railsチュートリアル5章の学び

  • クラスとidの違い クラス:ページの中で何度でも使用ができる id:一度しか使用できない

  • 画像はapp/assets/imagesに置きimage_tag("ファイル名", alt: "属性名")で呼び出す

  • .(ドット)はクラスを表します

  • Atomエディタでのコメントアウト方法は「Commnad + /」

  • アセットディレクト

  • app/assets: 現在のアプリケーション固有のアセット
  • lib/assets: あなたの開発チームによって作成されたライブラリ用のアセット
  • vendor/assets: サードパーティのアセット

  • アセットをまとめる処理を行うのはSprocketsというgem

  • リダイレクトの場合のみ_url書式を使用

  • pathとurlの違い

  • 統合テスト (Integration Test)の実行方法

    • $ rails test:integration

railsチュートリアル5章の演習解説

5.1.1 演習 ナビゲーション

5.1.1.1

<問題> Webページと言ったらネコ画像、というぐらいにはWebにはネコ画像が溢れていますよね。リスト 5.4のコマンドを使って、図 5.3のネコ画像をダウンロードしてきましょう。

<回答>

$ curl -OL cdn.learnenough.com/kitten.jpg

5.1.1.2

<問題> mvコマンドを使って、ダウンロードしたkitten.jpgファイルを適切なアセットディレクトリに移動してください (参考: 5.2.1)。

<回答>

$ mv kitten.jpg app/assets/images/kitten.jpg

5.1.1.3

<問題> image_tagを使って、kitten.jpg画像を表示してみてください (図 5.4)。

<回答>

# app/views/static_pages/home.html.erb
<div class="center jumbotron">
  <h1>Welcome to the Sample App</h1>

  <h2>
    This is the home page for the
    <a href="http://railstutorial.jp/">Ruby on Rails Tutorial</a>
    sample application.
  </h2>

  <%= link_to "Sign up now!", "#", class: "btn btn-lg btn-primary" %>
</div>

<%= link_to image_tag("rails.png", alt: "Rails logo"), "https://rubyonrails.org/" %>
<%= image_tag("kitten.jpg", alt: "cat logo") %>

5.1.2 演習 BootstrapとカスタムCSS

5.1.2.1

<問題>リスト 5.10を参考にして、5.1.1.1で使ったネコ画像をコメントアウトしてみてください。また、ブラウザのHTMLインスペクタ機能を使って、コメントアウトするとHTMLのソースからも消えていることを確認してみてください。

<回答>

<!-- <%= image_tag("kitten.jpg", alt: "cat logo") %> -->

5.1.2.2

<問題>リスト 5.11のコードをcustom.scssに追加し、すべての画像を非表示にしてみてください。うまくいけば、Railsのロゴ画像がHomeページから消えるはずです。先ほどと同様にインスペクタ機能を使って、今度はHTMLのソースコードは残ったままで、画像だけが表示されなくなっていることを確認してみてください。

<回答>

img {
  display: none;
}

5.1.3 演習 パーシャル(partial)

5.1.3.1

<問題>Railsがデフォルトで生成するheadタグの部分を、リスト 5.18のようにrenderに置き換えてみてください。ヒント: 単純に削除してしまうと後でパーシャルを1から書き直す必要が出てくるので、削除する前にどこかに退避しておきましょう。

<回答>

# app/views/layouts/_rails_default.html.erb
<%= csrf_meta_tags %>
<%= stylesheet_link_tag    'application', media: 'all', 'data-turbolinks-track': 'reload' %>
<%= javascript_include_tag 'application', 'data-turbolinks-track': 'reload' %>

5.1.3.2

<問題>リスト 5.18のようなパーシャルはまだ作っていないので、現時点ではテストは redになっているはずです。実際にテストを実行して確認してみましょう。

<回答> redになる!

5.1.3.3

<問題>layoutsディレクトリにheadタグ用のパーシャルを作成し、先ほど退避しておいたコードを書き込み、最後にテストが green に戻ることを確認しましょう。

<回答> greenになる!

5.2.2 演習 アセットパイプライン

5.2.2.1

<問題> 5.2.2で提案したように、footerのCSSを手作業で変換してみましょう。具体的には、リスト 5.17の内容を1つずつ変換していき、リスト 5.20のようにしてみてください。

<回答>

/* footer */

footer {
  margin-top: 45px;
  padding-top: 5px;
  border-top: 1px solid $gray-medium-light;
  color: $gray-light;
  a {
    color: $gray;
    &:hover {
      color: $gray-darker;
    }
  }
  small {
    float: left;
  }
  ul {
    float: right;
    list-style: none;
    li {
      float: left;
      margin-left: 15px;
    }
  }
}

5.3.2 演習 RailsのルートURL

5.3.2.1

<問題>実は名前付きルートは、as:オプションを使って変更することができます。有名なFar Sideの漫画に倣って、Helpページの名前付きルートをhelfに変更してみてください。

<回答>

 rails routes
 Prefix Verb URI Pattern        Controller#Action
   root GET  /                  static_pages#home
   help GET  /help(.:format)    static_pages#help
  about GET  /about(.:format)   static_pages#about
contact GET  /contact(.:format) static_pages#contact
rh0257:railstutorial_5 taku$ rails routes
 Prefix Verb URI Pattern        Controller#Action
   root GET  /                  static_pages#home
   helf GET  /help(.:format)    static_pages#help # 「helf」になっていることを確認!
  about GET  /about(.:format)   static_pages#about
contact GET  /contact(.:format) static_pages#contact

5.3.2.2

<問題>先ほどの変更により、テストが redになっていることを確認してください。リスト 5.28を参考にルーティングを更新して、テストを greenにして見てください。

<回答> できた

5.3.2.3

<問題>エディタのUndo機能を使って、今回の演習で行った変更を元に戻して見てください。

<回答> Command + z

5.3.3 演習 名前付きルート

5.3.3.1

<問題>リスト 5.29のようにhelfルーティングを作成し、レイアウトのリンクを更新してみてください。

<回答> <%= link_to "Help", helf_path %>にしても/helpにジャンプすることを確認した

5.3.3.2

<問題>前回の演習と同様に、エディタのUndo機能を使ってこの演習で行った変更を元に戻してみてください。

<回答> Command + z

演習 5.3.4 リンクのテスト

5.3.4.1

<問題> footerパーシャルのabout_pathをcontact_pathに変更してみて、テストが正しくエラーを捕まえてくれるかどうか確認してみてください。

<回答>

$ rails test
Running via Spring preloader in process 49273
Started with run options --seed 21667

 FAIL["test_layout_links", SiteLayoutTest, 0.8195362979986385]
 test_layout_links#SiteLayoutTest (0.82s)
        Expected at least 1 element matching "a[href="/about"]", found 0..
        Expected 0 to be >= 1.
        test/integration/site_layout_test.rb:9:in `block in <class:SiteLayoutTest>'

  5/5: [============================================================================================================================================================] 100% Time: 00:00:00, Time: 00:00:00

Finished in 0.95899s
5 tests, 12 assertions, 1 failures, 0 errors, 0 skips

5.3.4.2

<問題> リスト 5.35で示すように、Applicationヘルパーで使っているfull_titleヘルパーを、test環境でも使えるようにすると便利です。こうしておくと、リスト 5.36のようなコードを使って、正しいタイトルをテストすることができます。ただし、これは完璧なテストではありません。たとえばベースタイトルに「Ruby on Rails Tutoial」といった誤字があったとしても、このテストでは発見することができないでしょう。この問題を解決するためには、full_titleヘルパーに対するテストを書く必要があります。そこで、Applicationヘルパーをテストするファイルを作成し、リスト 5.37のFILL_INの部分を適切なコードに置き換えてみてください。ヒント: リスト 5.37ではassert_equal <期待される値>, <実際の値>といった形で使っていましたが、内部では==演算子で期待される値と実際の値を比較し、正しいかどうかのテストをしています。

<回答>

# test/helpers/application_helper_test.rb
require 'test_helper'

class ApplicationHelperTest < ActionView::TestCase
  test "full title helper" do
    assert_equal full_title, 'Ruby on Rails Tutorial Sample App'
    assert_equal full_title("Help"), 'Help | Ruby on Rails Tutorial Sample App'
  end
end

5.4.1 演習

5.4.1.1

<問題>表 5.1を参考にしながらリスト 5.41を変更し、users_new_urlではなくsignup_pathを使えるようにしてみてください。

<回答>

# routes.rb
  get '/signup', to: 'users#new'
# rails routesコマンド
$ rails routes
 Prefix Verb URI Pattern        Controller#Action
   root GET  /                  static_pages#home
   help GET  /help(.:format)    static_pages#help
  about GET  /about(.:format)   static_pages#about
contact GET  /contact(.:format) static_pages#contact
 signup GET  /signup(.:format)  users#new ← `signup`が追加されていることを確認!

5.4.1.2

<問題>先ほどの変更を加えたことにより、テストが redになったことを確認してください。なお、この演習はテスト駆動開発 (コラム 3.3) で説明した red/green のリズムを作ることを目的としています。このテストは次の5.4.2で greenになるよう修正します。

<回答> OK

5.4.2 演習

5.4.2.1

<問題>もしまだ5.4.1.1の演習に取り掛かっていなければ、まずはリスト 5.41のように変更し、名前付きルートsignup_pathを使えるようにしてください。また、リスト 5.43で名前付きルートが使えるようになったので、現時点でテストが greenになっていることを確認してください。

<回答>

# rails testコマンド
$ rails test
Running via Spring preloader in process 2676
Started with run options --seed 22738

  7/7: [============================================================================================================================================================] 100% Time: 00:00:00, Time: 00:00:00

Finished in 0.89370s
7 tests, 17 assertions, 0 failures, 0 errors, 0 skips

5.4.2.2

<問題>先ほどのテストが正しく動いていることを確認するため、signupルールの部分をコメントアウトし、テスト redになることを確認してください。確認できたら、コメントアウトを解除して greenの状態に戻してください。

<回答> OK コメントアウト#で、元に戻すときはCommand + z

5.4.2.3

<問題>リスト 5.32の統合テストにsignupページにアクセスするコードを追加してください (getメソッドを使います)。コードを追加したら実際にテストを実行し、結果が正しいことを確認してください。 ヒント: リスト 5.36で紹介したfull_titleヘルパーを使ってみてください。

<回答>

# test/integration/site_layout_test.rb
require 'test_helper'

class SiteLayoutTest < ActionDispatch::IntegrationTest
  test "layout links" do
    get root_path
    assert_template 'static_pages/home'
    assert_select "a[href=?]", root_path, count: 2
    assert_select "a[href=?]", help_path
    assert_select "a[href=?]", about_path
    assert_select "a[href=?]", contact_path
    get contact_path
    assert_select "title", full_title("Contact")

    get signup_path ← 追加!
    assert_template 'users/new' ← 追加!
  end
end

好きなことで生きていくって難しいよ

会社では新卒を除いて僕が一番若い

20代は僕以外に多分一人しかいない

先輩達のほとんどが中途組だから人生の参考にはならない


さっきTwitter見てたら2020年には年収400万以下の人が6割になるってニュースを見た。

まー当たり前だろうし、そんな事は分かっているのだけど改めて言われると夢がないなーって思う。


ある程度大きな会社に入ればだいたいこのくらいで年収いくら、あーなったら出世コースでとか分かるっていう。実際にあーあいつは出世コースだなみたいな話もするらしいので本当だろう。

先ずこのレースに参加できるのは学生時代必死に勉強して良い大学に入った人達だけだ。

大学を卒業してなければ就職活動に参加することすら出来ない


いやいや今の時代40年間続く会社は4社くらいしかない

あれだけ大きな会社だった今の時代どうなるか分からない

だからこそ好きなことをやらないと生きていけない


そんな言葉がネットの世界では溢れているが、好きなことだと思って専門学校に行くという人生を歩んで来た人間から言わせると本当にそれ好きか?

それが好きな人達の中に飛び込むと圧倒される。そこでなんて最高な世界なんだって思えればそれは本当に好きなんだろうけど大体の人は場違いの場所に来たってなると思うよ。だって熱量が違い過ぎる。

専門的な事をするって簡単に言うけど間違いなく上には上がいるしそもそも普通のサラリーマンをするより門はめちゃくちゃ狭いぞ。


ただ、その中でもがき苦しみ突き抜けた人ってのは間違いなく成功する。

僕の知り合いは最初全然冴えない感じだったけど今では業界でも知名度のある凄い奴になっている。(まー元々馬鹿みたいにカッコ良かったから殻を破れてなかっただけかもしれないが)

最後に

とまー色々最近考えることがあって人生について悩み苦しんでいるのだけど好きなことで生きていくってのは大変ですよって話です。

だけど普通に生きていたら400万の人生しか生きれない。

じゃーどうするか。


藤原先生の「レアカード」になるって考え方がきっと確実に生きていく方法、正解なんだと思います。 たとえ好きな事じゃなくても100分の1を積み重ねていくことで自分の価値を上げる。 今周りにある環境で100分の1を先ずは目指す。何かに挑戦して100分の1を目指す。その繰り返し繰り返しが結果的に自分の価値を高める=レアカードになれる。

好きな事だから頑張れるってのは勿論あると思うけど、そればっかりに頭を使うんじゃなくて色々な要素を掛け算して考えるってのがすごい大事。

うーん何か言いたいことと違った結論になってしまったような。まー今日はこんな感じ。

しっかり握っておかないと心はすぐに離れてしまうから

最近いろいろとバタバタとしていて、子供たちと接する時間が取れてなかった。


昨日やっと色々落ち着いて子供たちと遊ぼうとするのですが何するにも壁があるような。

娘は絶対朝送ってくれるのにそれがない。帰った時の「パパだいずき」がない。「しょうぎしょうぎ」っていわない。

物理的な距離は確実に心の距離も遠ざける

これらは昨日一日で感じた事だから今日帰ったらな~んて事はないのかもしれない。

相手は子供だ。 子供は環境に適応するのが本当に早いとよく言う。子供たちも幼稚園に行きだして集団生活になりきっと楽しいことばかりじゃないだろうけど、朝早く起きて支度をして幼稚園に行って弁当食べて帰ってくる。そんな日常が当たり前になっていく。

海外に転勤になった時、一番大変なのはママって聞く。子供たちは気づいたら当たり前の生活になってしまう。


全部いいことだけ取り上げればそうだが、逆だって当然だ。

居なくて当たり前になってしまったら、そのように振舞うしどう接すればよいかも分からない。

大人は色々な事情や想いを知っているし我慢が出来るから頑張れるけど子供は今見えている世界が全てである。

父との思い出はキャッチボールだけ

僕は父が嫌いだ。

僕は父と話した記憶がほとんど無い。

学生の頃、友達が父と一緒にエロ本見て遊んでたとか言ってたけど考えられなかった。だけどそんな父って良いなって思う。

どんな時も真面目で笑わず本を読んでいる。唯一の思い出は庭の水やりを終わった後の夕方のキャッチボールとチケットが当たったと言って連れてってもらった東京ドームオープン戦だ。

ずっとサッカーをやっていたのだけど何となく野球がしたくて小学校高学年から野球を始めた。自分中でも分からないきっと父と遊んだ唯一の野球という存在が忘れられなくて野球をやってのだと思う。


どんな仕事をしていたかは今となってやっと何となく分かるけど聞いたことなかったし、何が好きで何を思って生きてきたのか。あなたは人生楽しかったのだろうか。

僕は父から学んだことは正直ほとんど無い。目の前にはいるが僕の心にはいなかった。

最後に

まー色々と書いてきたが、子供の心はしっかりと握っておかなければすぐに何処かへ行ってしまうなと思った。って話です。


物理的に近くにいることは勿論だけど、それだけじゃなくしっかりと会話して伝えていく必要がある。

僕は子供にとって父でいたいし、大人になった時に一番の親友でいたい。

その為にも、今から自分がどう生きてきたのか、何か思っているのか、何を学んだのか。

今、目の前に見えている「あたりまえ」の世界は全然当たり前ではない

ドコモとミスチルの25周年記念動画を見たことがあるだろうか。


もし見たことが無ければ是非見てほしい。

私は重なる部分が多く、泣いてしまった。

今こうして思い出すだけでも少し目が重たくなってる気がする。

https://www.nttdocomo.co.jp/special_contents/25th/mrchildren/


私は今人生の大きな岐路に立っていると思っている。

まだ決まった訳では無いから多くの事は言えないのだが、こんなんも悩んだことは人生で思いつかない。


言いたいことは一つで、 人間何処かで頑張らないと本当の幸せを掴むことは出来ない。



動画の中でも高橋一生は単身赴任で遠くに出かけていってしまう。

一人娘がいるのだが、それまで娘はパパが大好きだったのに会えない。

誕生日には娘がダンスする動画をパパに送ったり本当に幸せそうにしている。


だが単身赴任が終わり家に帰ると娘と離れてしまった気持ちは取り戻すことが出来ず喧嘩ばかり。

当たり前だ。娘はずっと寂しかったのだ。

一度閉じてしまった心は中々開かない。



じゃーこの時パパは単身赴任なんてせずに家にいればよかったんじゃないか。家族と一緒に引っ越せば良かったんじゃないか。離れてしまうくらいなら仕 事を変えればよかったんじゃないか。

そんな風に考える人もいるかもしれないが、「生きる」ってそんな簡単な話じゃない。相当な覚悟を持ってきっと決断したのだと思う。

きっと「今」ではなく「未来」が幸せであれと願い、想い、出した答えだったのだろう。


何が正解かなんて、僕たちは今を歩いているのだから未来のことは分からない。

「忙しい」という言葉を言い訳に未来に対する危機感が全くない人達。

危機感いっぱいにもかかわらず行動できなきない人。

どんな答えを出したって想いを持っての行動ならば、それはきっと間違ってないのだと思う。

ただその決断をしたことで悲しんでいる人がいるかもしれない。迷惑をかけているかもしれない。

その想いをしっかり胸に刻み一歩ずつ前に進みだそう。きっと良い未来が待っている。