2016-12-17

がんばるための行動指針

本エントリは「行動指針 Advent Calendar 2016」の16日目の記事です。

キリがいいので、3つ書きます。

がんばらない

残業したり、がんばったり、根性論が嫌いなので、極力がんばらない為にどうするかをがんばります。嫌いだと言いましたが、詳しく言うと、"出来ない"です。体力がなさ過ぎて、がんばることが出来ないから、手段、ツール、知識、テクニックを用いて、がんばらないようにがんばります。がんばれる人は本当にすごいと思います。おれはそれがしたくでも出来ないです。当たり前ですが、あらゆる事を駆使して効率的に長時間がんばれたらそれが最強です。

これは、仕事に限らない話しです。ゲームとかもそうですが、最近だと、効率を求めずにだらだらやる楽しみ。というのもわかってきました。エンジョイ勢ってやつですね。

がんばらない2

努力ができることは才能だと思います。周りがあの人は努力家だ。と思っていても、本人は努力だとは思っていないことが多いと思います。

自然にできること。がんばらなくてもできること。が自分に合ってることだと思います。なので、今自分、がんばってるな。って思ったら、続けるか考えます。がんばらない程度に続けるか、違うことに時間を使うか。これもなんでもそうです。仕事、人付き合い、ゲーム etc・・

物事の背景、理由、先にあることを考える。

これは仕事だけに限定しておきます。我々エンジニアの仕事は、コードを書いて何かを作ること。だけではないです。何のためにこの機能を実装するのか。を考えたり、この機能を実装したあとで、何を期待しているのか。を考えたり、そもそもこの機能はいるんだっけ。を考えたり、技術的な観点で、この機能よりこっちのほうがいいかも。を考えたり、、、

全ての、仕事や行動などには理由があるべき、あるはずで、それをする理由がないならしないほうがいいかもしれません。ここらへんは、状況に寄りすぎるので断定はしません。

また、これは自分が誰かに仕事を依頼する場合にも重要です。背景、理由、あとの展望は成果物の質に大きく影響します。

まとめ

まとめると、全部自分を中心に考えています。 3つ目は物事の本質を捉えようとしている。とかかっこよくいえますが、こういう考え方で仕事をしたほうが仕事量は減るからです。自分を安定させてないと、他の（人の）事を考えられないので。

2016-11-13

factory_girlの使い方を全体的にまとめた

factory_girlとは

factory_girlとは、 Rspec等の、Rubyのテストフレームワークで使用する、テストデータ生成のためのライブラリ。

使い所

おもに、Activerecordのデータを生成することに長けている。 Activerecord以外のデータも生成可能だが、生成ロジック等は自身で書くことになる。

併用ライブラリ

テストデータ生成といっても、データの中身は別途用意する必要がある。そこで使われるのは、faker。 fakerの使い方は公式のReadmeを一部引用して軽く説明。

以下のような、記述で簡単に、ダミーデータを作成できる。

Faker::Name.name      #=> "Christophe Bartell"
Faker::Internet.email #=> "kirsten.greenholt@corkeryfisher.info"

fakerと組み合わせてfactorygirlを使っていく。

単一テーブルのデータ生成

テーブル

+-----------------+--------------+------+-----+---------+---------------------+
| Field           | Type         | Null | Key | Default | Extra               |
+-----------------+--------------+------+-----+---------+---------------------+
| user_id         | int(11)      | NO   | PRI | NULL    | auto_increment      |
| nickname        | varchar(100) | NO   |     | NULL    |                     |
| created_at      | datetime     | NO   |     | NULL    |                     |
| updated_at      | datetime     | NO   |     | NULL    |                     |
+-----------------+--------------+------+-----+---------+---------------------+

モデル

class User < ActiveRecord::Base
end

上記のような、usersテーブルがあったとする。これを、factorygirlで生成する。

FactoryGirl.define do
  factory User do
    nickname { Faker::Name.name }
  end
end

上記がfactorygirlの定義

id, created_at, updated_at は activerecord側で生成されるので、 nicknameだけを指定すればよい。

user = create(:user)

生成時は上記のように書けばいい。

補助的なデータの生成

例えば、user生成時に指定したユーザーとフレンド関係になっていてほしいとか

Friendsテーブルがあるとする。

id
user_id
friend_id
created_at
updated_at

FactoryGirl.define do
  factory User do
    nickname { Faker::Name.name }
    
    factory :friend do
      transient do
        friend_id ''
      end
      
      after(:create) do |user, evaluator|
        Friend.new(user_id: user.id, friend_id: evaluator.friend_id)
      end
    end
  end
end

user = create(:user)
friend = create(:friend, friend_id: user.id)

factory定義中にfactoryを定義することができ、これを行うとfactoryを継承することができる。

上記の場合は、Userを継承し:friendを作成している。

factoryの定義では、factoryの生成周りで、callbackが呼ばれる。

after(:build)
before(:create)
after(:create)
after(:stub)

stub以外は、activerecodのbuild,create前後のことだと考えてOK stubについては今回は扱わない。

transientは一時データを、初期から定義、外部から渡すことが可能。今回は、friendになるユーザーのIDを外部から渡している。

最初からフレンドを持っているユーザーを生成する

ユーザー生成時に、フレンドもついでに作成したいケースもある。 factoryの定義に、traitを指定して、factory生成にパターンを持たせる事ができる。

FactoryGirl.define do
  factory User do
    nickname { Faker::Name.name }
    
    trait :with_friends do
      transient do
        friend_count 1
      end
      
      after(:create) do |user, evalutor|
        evalutor.friend_count.times.each do |_i|
          Friend.new(user_id: user.id, firned_id: create(:user).id)
        end
      end
    end
  end
end

user = create(:user, :with_friends, friend_count: 2)

これで、user生成時に、friendを指定数だけ一緒に生成する定義が出来る。今回は追加データを生成するパターンに使っているが、作成するデータのデータ内容のパターンに使うことも可能。

belongs_toが関係のデータ生成

Userモデルに従属しているテーブルがあったとします。

PostsテーブルとUserモデル、 Postモデル定義

id
user_id
created_at
updated_at

class User < ActiveRecord::Base
  has_many :posts
end
class Post < ActiveRecord::Base
  belongs_to :user
end

Postモデルのデータ生成時に、依存しているデータの生成も併せて行えます。

FactoryGirl.define do
  factory Post do
    user
  end
end

post = create(:post)

userモデルに従属しているということをPostファクトリ定義時に指定している。これは、以下の記述と同様の意味になっている

FactoryGirl.define do
  factory Post do
    association :user, factory: :user
  end
end

user = create(:user)
poset = create(:post, user: user)

逆に、Userのデータはすでに生成済で、そのUserに対してPostのデータを生成したい場合は上記のように、引数として渡すことができる。

従属している側から生成することはあんまりない気がするので、たいていの場合は後者の記述。もしくは、friendのときのように、 :with_postsみたいにtraitでpost持ちのUserを生成する定義を書いたほうが使いやすい。

その他

別のテーブルの関係とかは、だいたい、after(:create)とか before(:create)とか、使えば、なんでも作れる。

traitでパターンを定義したが、複数パターンを組み合わせたい場合は、別途定義ができる

factory :male_admin,   traits: [:male, :admin]   # login will be "admin-John Doe"
factory :female_admin, traits: [:admin, :female] # login will be "Jane Doe (F)"

単一のtraitの場合は、factoryの引数に指定していたが、複数を組み合わせる場合は別factoryとなる。

user = create(:male_admin)

まとめ

factorygirlの機能を組み合わせると、細かくパターンごとにテストデータの生成が可能になる。うまく定義することで、テストコードのデータ作成部分がスッキリするのでおすすめ。

ここに書いたことは、全部公式にのっている

2016-11-06

転職して1年がたったので振り返ります。

一応退職エントリ（のつもり）です。

だれですか

@astapi （あすたぴ）といいます。

IT系の受託開発の会社で新卒から9年働いていました。

顧客は割りと大きめの会社で、内容は言えないのですが結構面白い仕事もやらせてもらっていました。

2015年11月1日にSupership株式会社に入社し、1年が経ったのでこの1年でやったことを振り返ってみようと思います。

転職をしたいと思った理由

転職をしたいと思った理由としては3つあります。

1つ目が一番大きな理由ですが、エンジニアとして働きたかったです。

9年も働いていると自然と管理職になり、自然とコードが書く量が減っていきました。そういう仕事ではなく、ちゃんと自分の手でコードを書きたかったです。

2つ目は開発の環境です。

受託開発である以上、顧客から開発環境（言語、サーバー）等を指定されることも多いです。且つ、昔から続いている、保守案件も多かった為、アーキテクチャ的には古いものが多くありました。

3つ目は、自分がサービスを作ってる感がほしかったです。

受託開発のため、自分がこれを作っている。このサービスをやっている。というのはなかなか言えません。もっと、自分がこれを作っているんだ。いいものを作って世に出したい。という思いを持って、開発がしたかったです。

転職してからやったこと - 勉強編

自分に実力が足りないことはわかっていたので必死に学びました。具体的には、

基礎を学ぶ
スキルを深める
エンジニアとしての活動の幅を広げる

の3つです。

基礎を学ぶ

自分は専門学校卒できちんとしたコンピューター・サイエンスを学んでいません。なので、コンピュータ、プログラミングの基礎、歴史からしっかり学ぼうと思ってこれらを読んでいました。

どんな技術でも、最終的にはコンピュータに命令を行うことになります。その際に使用している、システムコールを意識することはたまにはあるかもしれません。自分の使っている言語、ライブラリなどが最終的にコンピュータに対してどのような命令を行っているのか、明確に見なくてもイメージすることは、その技術を正しく使うにあたって重要だと思います。

歴史を知ることはいまの技術の理解につながります。技術は、日々時代と共に、進歩を続けてきていますが、古い技術はもう使えないということはなく、新しい技術でも古くからの伝統的な素晴らしい考えに沿っているものがほとんどです。歴史を知ることはいまの技術の理解につながります。

読み終わっていないものも多いので、絶対にちゃんと読みますｗ

スキルを深める

現在、サーバーサイドエンジニアとして、APIを作っています。サーバーサイドといっても、アプリのコードを書くだけではなく、意味合い的にはフロント以外のすべてをやる。という意味です。それに必要な技術を深掘りしようとしました。

インフラ

プロジェクトはオンプレではなく全AWSなので、AWSでも通じる知識、AWSではどうするのか。 itamae, packer, terraform, cosul等のインフラ構築ツールを学びました。基盤こそ、インフラエンジニアの方が作ったものですが、いまは、私がサービスのインフラ改修も行っています。

インフラは全部コード化されていて、AWSのコンソールから直接構築することはありません。 AMIのイメージはpackerで構築しています。とはいっても、AMIの作り直しは言語のversionが上がったり、した時くらいです。 AWS環境の構築はterraformで行われています。 AWS上のインスタンス間はconsulでクラスタ化されていて、 deploy時はconsulのリーダーからクラスタのメンバーへ通知を行ってます。

サーバーサイド

プロジェクトでElixirを使ってるので、ErlangとElixirをやりまくってました。 Elixirは、ErlangVM上で生成される軽量プロセスを大量に利用した、並行、並列処理が得意で、非同期処理を頻繁に使いたいシステムと親和性が高いです。

Rubyは、プロジェクトで使っているのもあり、しっかりと学ぼうとしました。

新しい技術を学ぶときは、既存の技術には何か問題があり、問題を解決するために新しい技術を作っている人がいる。どんな問題をどう解決しようとしているのか？を考えると、その技術の使い所、使い方を見えやすくなるのでおすすめです。

エンジニアとしての幅を広げる

他、業務とは関係ないですが以下のようなこともやりました。上司との1on1で、こういうことをやりたいんです。って言ったら、じゃあやってみよう。って背中を押してもらったのでやりました。

オープンソースへの関与など

ライブラリを作った。
OSS開発
- てきとうにgithubで探したライブラリにpull requestを送った。
- 感謝されたけど、取り込まれはしなかった。
- やり取りが暖かくて嬉しかった。（英語）

勉強会での登壇や運営への参加

Elixirの勉強会 tokyo.ex にて、LTと、パネルトークをしました。

Elixirを本番で導入しているという観点から、多少は話せたのかな・・・。

ご縁があり、運営としても参加させてもらっています。（積極的に手伝えておらず、申し訳ないです。）

転職してからやったこと - 仕事編

非常に楽しく仕事ができました。

楽しく仕事ができる環境を用意してもらい、本当にありがとうございます。一番良かったことは、任せてもらい、失敗をさせてもらえたことです。（勝手に失敗して勝手に直してる）

自分で設計して、自分で導入して、自分で失敗に気づいて、自分で改善策を調べて自分で直しました。

1つのサービスで、機能追加や改修のたびに、（自分で書いた）良くない部分を直しつつ、進めてきました。これが非常に、よかったです。

デザインパターンや、コードの設計に関することが非常に苦手で、どこに適用すればいいのか、適用したらどうなるのかがいまいちイメージが出来ていませんでした。自分が失敗したと、思ったことをパターンに当てはめて、改善することで初めて、使えるようになったと思っています。

振り返り

プライベートの学習を振り返ってみると、これだけしかやっていないのかと思いました。

自分的には、なんとなく1年前に比べたらかなり成長したなぁ。

という感覚があったのですが、まとめてみると、あっさりしている気がします。

昔はアウトプットを意識していたのですが、この1年はインプットの割合が多すぎました。これからは、学んだことをしっかりと自分のためにも残していこうと思います。

終わりに

最近読んだ中で好きなマンガで、BlueGiant、ベイビーステップがあります。

この2つの本に共通しているのは、最初から強い、何か特別な能力を持っているわけではない主人公が、地道に地道に1つ1つを積み重ねて成長していく。というところです。

自分は、そんなに頭が良いわけでもなく、理解が早いわけでもないので、この本の主人公たちのように1つ1つを積み重ねていかないとダメだと思っています。

これからも、いまよりがんばって積み重ねていきたいと思っています。ここまで読んでくれてありがとうございました！！！

おまけ

Supership株式会社ではエンジニアを募集しています。

興味がある方はSupership HP,wantedllyから応募するか、

私にお声がけください。

2016-10-23

個人の開発環境について

プライベートではなく、仕事で開発をする際に、

他のところは、どのような開発環境を構築しているのだろうか。

技術的な環境と、仕組み的な環境にわけられると思うが、

技術的な環境

ローカルのWindows、Macに構築する。
vagrant等のVM環境をローカルに乗せてその上に構築する。
docker等のコンテナを用いて、その上に構築する。
AWS,GCPにインスタンスを立てて構築する。

仕組み的な環境

全員が同じ環境になるようにしている。chef等のプロビジョニングツールで用いて容易に構築が可能。
手順だけ決まっていて、それぞれで構築する。
各自適当に構築している。

技術的な環境で言うと、割りとバラけてるような気がする。

最近ではdockerが多くなってきているのかな？

仕組み的な環境で言うと、そこそこしっかりしたところはプロビジョニングツールを使ってるだろうな。

自分の話し

これ。

vagrant等のVM環境をローカルに乗せてその上に構築する。
各自適当に構築している。

あんまりよくないですね。

もともとは、

ローカルのWindows、Macに構築する。
手順だけ決まっていて、それぞれで構築する。

だったんだけど、

ローカルに構築するのが好きではないので、

勝手に自分で環境を構築した。

自分用のvagrant環境と用意して、itamaeを書いて、構築できるようにしている。

個人的な考えとしては開発環境は、人によってやりやすさが違うと思うので、

自分で構築してトラブルが発生しても自分で解決するのであれば自由でいいと思っている。

あすたぴのブログ

astap(あすたぴ）のブログ