【雑記】今年の振り返り

まだ2017年が続くんじゃないか?と思うぐらい仕事をしていますが
今日でもう終わりと思うと昨年以上にあっという間の1年でした。

さて、今年を振り返ります。

今年の振り返り

部署異動

今年が始まり数ヶ月経ったころに部署を異動しました。
転職とは違いましたが、初めて出会う人たちと仕事をすることに
なるので最初はどうなるかと思いましたが、楽しく仕事を行うことができました。

出向

部署異動した後、諸事情になりグループ会社へ出向することになりました。
現在、出向先でサーバーサイドとクラウドインフラをやっています。
ちょこちょこ顔が出ているので知っていると思いますが、いろいろ聞きたければ
連絡をお願いします。

システム開発

Ruby on Railsでのシステム開発

異動した部署、出向先もAPIRailsで開発していて
それに携わることになりました。

仕様の理解とRubyの柔軟性にかなり苦労してしまい
一人前にまだRubyでご飯を食べられるような状態ではないことを
今年1年で痛感しました。

AWS, GCPに携われた

そんなにガッツリ!というほどではないですが
携われたことはとても大きく今後に繋がる内容だったと思います。

コンテナ技術

仮想マシンで十分だろう」と数年思っていたのですが
コンテナ技術を覚えなければならず、現在進行系でやっています。
Docker自体はそうでもないかな?と思ったのですが
Kubernetesを使うとかなり便利で使えるものだと実感させられ
来年はこの辺の知識をインプットしていければと考えています。

ブログ

実はこのブログ、月1で記事を書こうという目標があったのですが
結局、10 〜 11月は書くことができませんでした。

アウトプットを意識してのインプットができていなかった
時期だと思うのと良いインプットがなかったのでは?と反省です。

反省をしつつ来年は短いサイクルで振り返りを行い
意識して良いインプットをしつつ良いアウトプットを出していこうと思います。

プライベート

ウイスキー

今年の2月ぐらいにウイスキー検定3級を受けて無事に受かりました。
来年もあるのですが、ちょっと仕事方面に力を入れようと思うので
次、受けるのは再来年です。

ただ、来年はいろいろな種類のものを飲んで知見を広げるべく
1杯から飲めるところを巡ってみようと思います。

ゲーム機

3DSを買い換えることはあっても据え置き機はPS3を最後に買ってませんでしたが
今年は「Nintendo Swith」「PS4」を購入しました。

メジャータイトルはやりましたが、どれも中途半端に止まっている状況です。
せめてゼルダのエンディングだけはちゃんと見みます。

あ、PS4はモンハンワールドのために買ったので同じ人がいましたら一狩り行きましょう。

グラブル

昨年に引き続きグラブっておりました。
去年と同じように毎日コツコツとやっており中くらいのプレイヤーにはなったかな?
と思っていますが、ガチャは恐ろしい!

総評

仕事関連でいうとまさに怒涛の1年でした。
また、プログラマとして技術力がまったくついていっていないと
痛感する場面が今まで以上にあったのでマネジメントはやってきたので
来年は技術力アップを目指してやって行こうと思います。

後は、何事にも自信を持てる度胸を持つことです。

【Ruby】define_methodについて調べました

はじめに

せっかく調べたのに忘れてしまうため、メモを残しておく。

今回は、ライブラリの挙動を確認していたところ
define_methodが書かれており、復習も兼ねて調べました。

環境

前提条件

  • irbかPryが動作すること

やり方

define_methodに関すること

実行

[1] pry(main)> class Animal
[1] pry(main)*   { cat: 'にゃー', dog: 'わん' }.each do |name, message|
[1] pry(main)*     # 動的にクラスやモジュールを定義でき、defによるメソッド定義をしなくてもよい
[1] pry(main)*     # メソッド本体はブロックで記述する
[1] pry(main)*     define_method(name) do
[1] pry(main)*       message
[1] pry(main)*     end
[1] pry(main)*   end
[1] pry(main)* end
=> {:cat=>"にゃー", :dog=>"わん"}
[2] pry(main)>
[3] pry(main)> puts Animal.new.cat
にゃー
=> nil
[4] pry(main)>
[5] pry(main)> class Animal2
[5] pry(main)*   { cat: 'にゃー', dog: 'わん' }.each do |name, message|
[5] pry(main)*     # ブロックにブロック引数を加えるとブロック引数がメソッドの引数になる
[5] pry(main)*     # ブロック引数:name
[5] pry(main)*     define_method(name) do |num|
[5] pry(main)*       message * num
[5] pry(main)*     end
[5] pry(main)*   end
[5] pry(main)* end
=> {:cat=>"にゃー", :dog=>"わん"}
[6] pry(main)>
[7] pry(main)> # メソッドの引数:2
[8] pry(main)> puts Animal2.new.dog(2)
わんわん
=> nil
[9] pry(main)> class Animal3
[9] pry(main)* end
=> nil
[10] pry(main)>
[11] pry(main)> { cat: 'にゃー', dog: 'わん' }.each do |name, message|
[11] pry(main)*   # ブロックをオブジェクトとして定義する
[11] pry(main)*   proc = Proc.new { |num| message * num }
[11] pry(main)*   # class_evalは、ブロックをクラス定義やモジュール定義の中のコードであるように実行する
[11] pry(main)*   # ブロックの戻り値がメソッドの戻り値になる
[11] pry(main)*   Animal3.class_eval { define_method(name, proc) }
[11] pry(main)* end
=> {:cat=>"にゃー", :dog=>"わん"}
[12] pry(main)>
[13] pry(main)> puts Animal3.new.cat(3)
にゃーにゃーにゃー
=> nil

まとめ

defでメソッド定義しなくてもメソッドを定義するという
初見殺しな面もありますが、メタプログラミングをする上で
扱うものの1つだと思うのでしっかり覚えておきます。

参考資料

define_method (Module) - Rubyリファレンス

【アジャイル】アジャイル(スクラム)をやり始めて5ヶ月ほど経ったので振り返る

はじめに

本エントリーは以下の続きです。

fujiyasu.hatenablog.com

fujiyasu.hatenablog.com

前回のエントリーから今まであったこと

  • プロダクトオーナー(以下、PO)が交代
    • POが認定POを取得
  • スクラムマスター(以下、SM)が交代
    • SMが認定SMを取得
  • チームが成熟されてきたときに起きたこと
    • プロダクトバックログリファインメントの改善
    • スプリントレビューの改善
    • T字型人材への促進
  • スクラムオブスクラムが始まる動きがある

簡単ですが、こんなところでしょうか。
それでは詳しく書いていきます。

プロダクトオーナー(以下、PO)が交代

前回のエントリーで

POがいない問題

というのを書きました。

前のPOも問題詩しており、解決策として
プロダクトに近い立場の人を新POにしました。
ただし、人が変わるということは会話の内容が変わってくるため
最初は認識合わせすることにかなり苦労しました。

しかし、開発をしていくごとに改善してきて
会話できる時間や量も増えて、スプリント中でも
スムーズに意思疎通をすることができるようになりました。

なお、この前後にPOは認定POを取得しており
POとしての基礎固めはできている状態となりました。

スクラムマスター(以下、SM)が交代

前SMが築き上げてきたものを筆者が引き継ぎ、新SMとなりました。
POのときと同様にそれぞれ認定SMを取得した状態です。

交代した理由は「認定SMを取得したのでやってみる」というのも
ありますが、もう1つの理由は「SMは思っている以上に大変」ということだと
思います。
常にチームを観察して、正しい方向に導き細かいタスクをやらなければならないので
1つのことに集中する以上に労力を使う立場です。
そのため、ずっとSMは現実的に難しいと思うので交代はありだと考えています。

また、前回のエントリーで

すでにローンチ済みのサービスのため、本番の調査依頼などが入ってくる

というのを書きましたが、POがすぐに対応できない場合
SMとして間に入ってSMがまず調査をすることにしていました。
どうしてもわからない、時間がかかる場合はPOに相談して
開発チームのリソースを使うということをしました。

チームが成熟されてきたときに起きたこと

プロダクトバックログリファインメントの改善

改善点

  1. 一つのストーリーに費やす時間が多かったのでキッチンタイマーを導入して10分の制限を設けた。
  2. 議論が白熱した際、SMが間髪入れず間に入って状況を整理する。
  3. リファインメントでは詳細な機能の話はしない。詳細に考えなければいけないのを含めてポイントを出す。
  4. 毎日1時間やっていたリファインメントを週にまとめて2時間にして効率化を目指す。

上記のおかげで今までストーリーポイントすらなかった状態が
見積もりされたバックログがある状態となってきました。

スプリントレビューの改善

改善点

  1. スプリントレビューのやり方を調べてチーム展開して、共通認識を行った。
  2. 大きなモニタを使って全員で画面を見れるようにした。
  3. 離れた場所から参加する人がいたので、TV会議システムを使い同じ画面を見れるようにした。

スクラム以外でもレビューというのは行ってきましたが
全員集まってレビューというのは勝手が違う感じがしたようなので
最初は戸惑いもあったようですが、改善をした結果確かな手応えを
チーム全体で感じられたようなので良かったです。

T字型人材への促進

開発メンバーは、それぞれ得意分野というのがあり
そちらを伸ばして行く人が多い感じでした。
しかし、それだけでは属人化してしまうため一部のメンバーだけですが
ペアプロを実施していくようになりました。

現在進行系でやっていましたが、とても効率的であり
楽しくプログラミングをやっている印象を受けました。

スクラムオブスクラムが始まる動きがある

実は、別のチームでスクラムをやっているところがあり
それぞれのチームの知見を共有しようという話になってきました。
チームの文化というのは同じスクラムでもまったく違うので
お互いノウハウを共有していければと思います。

この辺は。また展開があったときに書きたいと思います。

まとめ

本当はもっとあったと思うのですが
詳しく書いてしまうと、それぞれの内容で1つのエントリーに
なってしまうレベルなので簡単に書きました。

スクラムチームとなって3ヶ月以上が経って
そろそろ半年になるにあたり、成熟度も増してきたので
今後、さらに良いチームになっていくと思います。

最後にSMとなって、参考にした書籍を列挙しておきます。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

【Ruby】文字列リテラルのダブルクォートとシングルクォートの違いについて

はじめに

せっかく調べたのに忘れてしまうため、メモを残しておく。

今回は、メソッドの引数に関することで
文字列リテラルのダブルクォートとシングルクォートの違いを調べました。

環境

前提条件

  • irbかPryが動作すること

やり方

文字列リテラルのダブルクォートとシングルクォート

文字列リテラルのダブルクォートとシングルクォート

実行

[1] pry(main)> # ダブルクォート
[2] pry(main)> # ・バックスラッシュ記法と式展開が有効になる
[3] pry(main)> str1 = "式展開も試してみます"
=> "式展開も試してみます"
[4] pry(main)> puts "ダブルクォートのサンプル文字列です\n\nそして、#{str1}"
ダブルクォートのサンプル文字列です

そして、式展開も試してみます
=> nil
[5] pry(main)>
[6] pry(main)> # 文字列内でダブルクォートを使いたい場合、エスケープ文字を入れる
[7] pry(main)> # ※「サンプル文字」をダブルクォートで括ってみる
[8] pry(main)> puts "ダブルクォートの\"サンプル文字列\"です\n\nそして、#{str1}"
ダブルクォートの"サンプル文字列"です

そして、式展開も試してみます
=> nil
[9] pry(main)>
[10] pry(main)> # シングルクォート
[11] pry(main)> # ・\\ (バックスラッシュそのもの)と \' (シングルクォート) を覗いて、文字列の中身の解釈しない
[12] pry(main)> str2 = "式展開されないことを確認します"
=> "式展開されないことを確認します"
[13] pry(main)> puts 'シングルクォートのサンプル文字列です\n\nそして、#{str2}'
シングルクォートのサンプル文字列です\n\nそして、#{str2}
=> nil
[14] pry(main)>
[15] pry(main)> # シングルクォートの場合、中身の会社はしないのでエスケープ文字を入れなくてもそのまま表示される
[16] pry(main)> puts 'シングルクォートの"サンプル文字列"です\n\nそして、#{str2}'
シングルクォートの"サンプル文字列"です\n\nそして、#{str2}
=> nil
[17] pry(main)>

まとめ

ダブルクォートとシングルクォートの違いに気づかず、シングルクォートで式展開を書いてしまっていて
なぜ展開されない?と数分考え込んでしまったので、簡単ですがまとめみました。

基本、ダブルクォートを使うのが良さそうなのでこちらを使っていきます。

参考資料

リテラル (Ruby 2.4.0)

【Ruby】キーワード引数

はじめに

せっかく調べたのに忘れてしまうため、メモを残しておく。

今回は、メソッドの引数に関することで キーワード引数を調べました。

環境

前提条件

  • irbかPryが動作すること

やり方

キーワード引数(デフォルト値あり)

キーワード引数(デフォルト値あり)のサンプルソース

実行

[6] pry(main)> # 引数を元にメッセージを表示する
[7] pry(main)> def display_message(name: 'Smith', message: 'Sample')
[7] pry(main)*   p "#{name} : #{message}"
[7] pry(main)* end
=> :display_message
[8] pry(main)>
[9] pry(main)> display_message
"Smith : Sample"
=> "Smith : Sample"
[10] pry(main)> display_message(name: 'John', message: 'Hello')
"John : Hello"
=> "John : Hello"
[11] pry(main)> display_message(message: 'Hello', name: 'John')
"John : Hello"
=> "John : Hello"
[12] pry(main)> display_message('John', 'Hello')
ArgumentError: wrong number of arguments (given 2, expected 0)
from (pry):8:in `display_message'
[13] pry(main)>

デフォルト引数を定義することで、何も受け取らなかった場合
デフォルトのものが表示されていることがわかります。

また、引数を設定するとその値にとなり、引数の順番を変えても
問題なく表示されていて便利です。

ただし、引数の値だけではエラーとなってしまいキーワードは必須です。

キーワード引数(デフォルト値なし)

キーワード引数(デフォルト値なし)のサンプルソース

実行

[13] pry(main)> # 引数を元にメッセージを表示する
[14] pry(main)> def display_message(name:, message:)
[14] pry(main)*   p "#{name} : #{message}"
[14] pry(main)* end
=> :display_message
[15] pry(main)>
[16] pry(main)> display_message(name: 'John', message: 'Hello')
"John : Hello"
=> "John : Hello"
[17] pry(main)> display_message(message: 'Hello', name: 'John')
"John : Hello"
=> "John : Hello"
[18] pry(main)> display_message
ArgumentError: missing keywords: name, message
from (pry):16:in `display_message'
[19] pry(main)> display_message('John', 'Hello')
ArgumentError: wrong number of arguments (given 2, expected 0)
from (pry):16:in `display_message'
[20] pry(main)>

デフォルト値なしの場合、エラーとなってしまったので
こちらを使った方がいい場合もありそうです。

まとめ

今まで意識して使ったことなかったのですが、明確に記述したい場合などがあったら
積極的に使っていきたい機能だと思いました。

ただし、参考資料先でも書かれている通り、冗長になる可能性が十分あるので
適材適所として使っていきます。

参考資料

改訂2版 パーフェクトRuby

改訂2版 パーフェクトRuby

ruby-rails.hatenadiary.com

robots.thoughtbot.com

【Ruby】可変長引数と配列の展開

はじめに

せっかく調べたのに忘れてしまうため、メモを残しておく。

今回は、メソッドの引数に関することで 可変長引数配列の展開を調べました。

環境

前提条件

  • irbかPryが動作すること

やり方

可変長引数

可変長引数のサンプルソース

実行

[12] pry(main)> # 引数を元にメッセージを表示する
[13] pry(main)> def display_messages(name, *messages)
[13] pry(main)*   messages.each do |message|
[13] pry(main)*     p "#{name} : #{message}"
[13] pry(main)*   end
[13] pry(main)* end
=> :display_messages
[14] pry(main)>
[15] pry(main)> # 実行
[16] pry(main)> display_messages 'John', 'Hello', 'Goodbye', 'Thank you'
"John : Hello"
"John : Goodbye"
"John : Thank you"
=> ["Hello", "Goodbye", "Thank you"]
[17] pry(main)>

値を個別に渡していますが、2つ目以降は配列として受け取られているのがわかります。

可変長引数

配列の展開のサンプルソース

実行

[39] pry(main)> # 引数を元にメッセージを表示する
[40] pry(main)> def display_messages(name, message_first, message_second)
[40] pry(main)*   p "#{name} : #{message_first}"
[40] pry(main)*   p "#{name} : #{message_second}"
[40] pry(main)* end
=> :display_messages
[41] pry(main)>
[42] pry(main)> # 実行(正常動作)
[43] pry(main)> messages = %w(Hello Goodbye)
=> ["Hello", "Goodbye"]
[44] pry(main)> display_messages 'John', *messages
"John : Hello"
"John : Goodbye"
=> "John : Goodbye"
[45] pry(main)>
[46] pry(main)> # 実行(例外発生)
[47] pry(main)> # 受取先のメソッドの引数以上に渡した場合、エラーとなる
[48] pry(main)> messages.push 'Thank you'
=> ["Hello", "Goodbye", "Thank you"]
[49] pry(main)> display_messages 'John', *messages
ArgumentError: wrong number of arguments (given 4, expected 3)
from (pry):50:in `display_messages'
[50] pry(main)>

まとめ

最初見た時は「なんだこれ?」と思いましたが、コーディング量が減るのはいいことで
使えるところには積極的に使っていきたいです。

ただ、変数名などをちゃんとしないと変に勘違いする可能性もあるかな?と思ったので
要注意のものだと感じられ巻いた。

参考資料

改訂2版 パーフェクトRuby

改訂2版 パーフェクトRuby

【Rails】Hash(key)をシンボル形式にする

はじめに

せっかく調べたのに忘れてしまうため、メモを残しておく。

今回は、APIなどで取得したHash値をRails側で処理しやすいようにするため
deep_symbolize_keysを調べました。

環境

前提条件

  • Railsアプリケーションのひな形が作成された状態で、Railsコンソールが起動できること

やり方

サンプルデータ

{
    "name": "Taro Tanaka",
    "gender": "male",
    "age": 24,
    "frends": [
        {
            "name": "Hanako Tanaka",
            "state": "NY"
        },
        {
            "name": "Jiro Tanaka",
            "state": "LA"
        }
    ]
}

実行

[1] pry(main)> response = {"name"=>"Taro Tanaka", "gender"=>"male", "age"=>24, "frends"=>[{"name"=>"Hanako Tanaka", "state"=>"NY"}, {"name"=>"Jiro Tanaka", "state"=>"LA"}]}
=> {"name"=>"Taro Tanaka", "gender"=>"male", "age"=>24, "frends"=>[{"name"=>"Hanako Tanaka", "state"=>"NY"}, {"name"=>"Jiro Tanaka", "state"=>"LA"}]}
[2] pry(main)> response.deep_symbolize_keys
=> {:name=>"Taro Tanaka", :gender=>"male", :age=>24, :frends=>[{:name=>"Hanako Tanaka", :state=>"NY"}, {:name=>"Jiro Tanaka", :state=>"LA"}]}
[3] pry(main)>

おぉ、シンボル化されたものになりました。
ちなみに「deep」とあるので、deepではないものを使うとどうなるか確認します。

[3] pry(main)> response.symbolize_keys
=> {:name=>"Taro Tanaka", :gender=>"male", :age=>24, :frends=>[{"name"=>"Hanako Tanaka", "state"=>"NY"}, {"name"=>"Jiro Tanaka", "state"=>"LA"}]}
[4] pry(main)>

なるほど、配列化されたところはそのままということですね。
基本的にはすべてシンボル化するはずなので、deep_symbolize_keysを使うことになりそうです。

参考資料

deep_symbolize_keys (Hash) - APIdock