プルリクとかレビューについて尊敬できるエンジニアに相談してみた話

誰かと開発することを忘れかけていて、
もぅマヂ無理。。。とりあえずLGTMしょ。。。
となりかけてしまったので、尊敬できるエンジニアである夫に相談してみました。

世の中の正解かは分からないですが、私は参考にしたいと思ったのでまとめます。

レビューの仕方がわからないです!!どこから見たらいいかわからないです!!

プルリクでは「意図」がわかるようにしたほうがいい。

夫が所属しているチームでは下記の内容をプルリクの説明(description)に書いているそうです。

なぜこの変更を入れるのか
バグだったらどういう問題があったか、機能だったらこれを入れたら何が改善されるのか(なにが嬉しいの?)

変更概要
変更概要を読むとdiffを見たときに意味がわかるように
こういう理由でこういう実装になっている、こういう理由でここは直さなくてもいい、などを書く

関連Issue
チケット(issue)へのリンク

影響範囲(テストすべき範囲)
どこに影響が出るか
この認識が実装者とレビュアでずれてたらおかしい
テスターがいる場合はテストすべき範囲がわかる

メモ(実装時に気になったことなど)
調べたもののリンク、ビミョーだけど今こうするしかないから今後こうしたいねという想い、なんでも

※上記を書いていたらプルリクが分かれるはず、とのことでした。

ちなみにプルリクのテンプレートというものがあるらしくGitHubでも設定できるそうです。
GitHubのIssue・Pull Requestのテンプレート機能を使おう - Qiita

「密にコミュニケーションとれるんだからそこまでしなくてもいいんじゃない」って言われたらどうすれば…?

次に入ってくる人はそれで困らないの?
まとまってない段階でコミュニケーションして、あなた( @maetoo11 )は困らないの?
→これは確かにそうで、私にとっては会話やチャットで聞き出すのは高コスト(MPの消費が激しい)ということを思い出しました。

「速さが大事だからそこまでしたくないんだよね」って言われたらどうすれば…?

そこまでしないならレビューしなくていいと思う
“そこまでしない"状態でレビューするのはやった気になってるだけ
→ううううううう(´-﹏-`;) 100%は無理でも意味のあるレビューできるようになりたいです…!

コミットの粒度は雑でもいいの?

そもそもこれを満たしたら(上記のプルリク説明を書くようにしたら)プルリクごとに読めるはず。(コミットは気にしなくてよくなるはず)
→これは場合によるかな、と私は思います。コミットごとにロールバックすることとかあるかもしれないですし。
粒度に関しては私は下記記事が参考になります。
【初心者向け】「コミットの粒度がわからない問題」の模範解答を考えてみた - Qiita

感想

夫と話して気づいたのですが、なぜここまで悩んだかというと
『意味のあるコードレビューがしたい』
と思ったからでした。

『JetBrainsのIDEはコードを書くということに集中できるようにつくられている。 それと同じようにプルリクの説明をきちんと書いたり、コミット粒度を考えたりするコストをかけてもレビューすることに集中できたほうがいい』
と思いました。

株式会社サムライズムに入社しました

タイトルのとおり、2017年8月1日に株式会社サムライズムへ入社しました!

f:id:maetoo11:20170804110245j:plain:w300
↑入社式の様子です。

何をしている会社なの?

f:id:maetoo11:20170804110206p:plain

サムライズムは国内外のエンジニア向け素敵ツールの販売を行っている会社です。
JetBrains製品や、Mackerel、GitHub Enterpriseなど取り扱っている製品がいろいろあります。

まえとーは何をするの?

受発注管理システムのメンテナンスから営業、事務、広報までなんでもやります!
なぜなら、しゃちょーと私の2人しかいない会社だからです。
このブログを更新しているときはOSC京都の出展で出張しています。

なんでサムライズムに入社したの?

できることだけやるよりも、できないかもしれないけどできたら面白そうなことにチャレンジしたかったからです。
あと、事務作業が得意というのをマイナスではなくプラスとして扱ってくださったので、自分の持ってる強みを活かせそうだと思いました。

不安はないの?

会社が大きくないことについての不安はありません。

いま1番の心配は英語がまったくダメなことです。
海外の製品も取り扱っているので開発元とのコミュニケーションが必要なのですが、私は読み・書き・会話のどれもダメダメです。
ただ、ずっと苦手だった英語を克服できたら嬉しいので、ちょっとずつ勉強していきたいです。

ワクワクしてることはないの?

IntelliJ IDEAやRubyMineちゃんのショートカットを覚えて、ドヤ顔できたらいいな!と思っています。( ・´ー・`)どや
あと、受発注作業をシステムの力で効率化したいです。
(かなり効率化されているのですが、しゃちょーの頭の中だけにあることがいっぱいあるので、それを取り出して整理していきたいな、とこっそり思っています)
業務改善が大好きなので、超楽しみです!


↑こんな感じのエンジニアを目指して行きたいと思います!(๑•̀ㅂ•́)و✧

オフィスは池袋にあるのでいつでも遊びに来てください。
Switchとスプラトゥーンを持ってくればしゃちょーと一緒に遊べますよヽ(=´▽`=)ノ
もちろん、弊社のハンズオンに参加してくださるのも大歓迎です!

これからもサムライズムとまえとーをどうぞよろしくお願いします。

感謝の正拳突き的なやつ(退職エントリ)

2015年5月に入社した株式会社Socket(現:Supership株式会社)を退職しました。
(正確には7月末付で退職します)

ちょんまげCTOとの衝撃的な出会いから、初めてのRailsScalaでの挫折、請求業務への挑戦などなど、色々なことがあってとても濃い時間を過ごすことができました。
本当は振り返りを書けるといいのですが、圧倒的に文才がないので、感謝したいことだけを書こうと思います。

f:id:maetoo11:20170705114604p:plain

感謝の正拳突き

Web業界ほぼド素人の私を雇ってくれた

本当に、驚きでした。
このフェーズで?!私ド素人だよ?!みたいな心配と役に立てるのだろうかという不安を抱えて入社しました。
この後にも書きますが、初めてのうぇっぶ業界で何もわからない私にとても丁寧に説明して、失敗したときはフォローして一緒に対策を考えてくれて、ピンチのときはギリギリまで粘るのを見守って一緒に戦ってくれて、本当に感謝しかないです。

挑戦も挫折も見守ってくれた

うまくいかないときも、新しいことに挑戦するときも、必ず誰かが声をかけてくださいました。
Scalaのプロジェクトから外れたいと相談したときはCTOとアーキテクトの先輩がそれぞれ時間をとってお話してくださいました。
請求業務をどうにかするプロジェクトに挑むときは、エンジニアだけでなく営業さんやバックオフィス担当の方など、色々な人が協力して応援もしてくださいました。
声をかけてくれる、話したら聞いてくれる、という環境は今までなかったのでとても嬉しかったし、失敗に必要以上に怯えることがなくなりました。

楽しいことをやればいいと教えてくれた

www.slideshare.net

各メンバーがお互いにそれぞれの大切なものを尊重していた

私が持っていない考え方だったので、文化としてそれが浸透している状態を知ることができて良かったです。
例えば、猫の調子がよくないから病院に連れて行ってから出社する、ということに対して、不満や陰口が出ませんでした。
新卒で入社した会社は「妻の体調が悪いので午後半休をとります」と帰った社員に対して「なんで帰るの…?仕事は?」という雰囲気が漂っていました。
そういうのが全くなく、パートナー、猫、自転車、山登りなど、それぞれが大切なものを尊重していました。
「お互いを尊重しなきゃ!」みたいなスローガンがあったわけではなく、ただ、それぞれが認めあっているような雰囲気でそれが大好きでした。

f:id:maetoo11:20170705114052j:plain:w400
写真は先輩宅のにゃんこさんに遊んでいただいたときのものです。

プログラミング以外のことにも挑戦できた

請求業務で使うサービス作成や業務フロー整理に挑戦できました。
プログラミング以外のことをやる時間が増えたときにエンジニアを名乗っていいか分からなくなってCTOに相談したら
「お前がやっていることはエンジニアリングだぜ。エンジニアリングっていうのは色んな形があるんだよ」
というメッセージをいただきました。
この言葉のおかげで、気持ちが楽になって腹をくくって請求業務の整備に挑戦することができました。


ありがとうございました!!!

素敵な会社で働くことができて、幸せでした。


今後について

またまたIT業界で働きます。
私にとっては大きなチャレンジなので、今からワクワクしています。

(2017/7/5 12:40 追記)
ほしいものリストを作ってみました!
退職ほしいものリスト

Rspecの書き方を先輩たちに質問してみた話

コードリファクタリング中にテストを書こうと思ったのですが、ふと考えたら私のRspec冗長な気がする…!と思い、会社のSlackで先輩方にRspecの書き方を質問してみました。

ちなみに私が書いていたテストコードはこんな感じ。

describe 'hoge_method' do
  context 'hogeがふむふむのとき' do
    example 'trueになること' do
      ・・・略・・・
      expect(piyo.hoge_method).to eq true
    end
  end
end

冗長かも?と思ったのははexampleとexpectの内容がほぼ同じだからです。

先輩方からのアドバイス

先輩01さんの場合

context "valid" do
  context "hogehoge" do
   it do
   end
  end
end 

context "invalid" do
  context "mogemoge" do
   it do
   end
  end
end

同一context(テストデータ)で複数 it はしてないです。

先輩02さんの場合

describe … テスト対象
context … xxの時
it … こうなる

って感じですね。itはシンプルな時は省略したり

先輩03さんの場合

itに引数与えたら負け

↓のように期待値がexpect読むだけで一目瞭然になってればベスト
it { expect(true).to be true }

it 'trueになる' { expect(true).to be true }は冗長

※「理想なので追い求めすぎると逆にコストかかるので適度なところで線引が必要」とのことでした!

その他書き方に関する意見やアドバイス

  • letを上書きしない
  • テストデータを共通化しないで、各テストで全部書くのがいいとは一概には言えない
  • letはoverrideできるのが便利なとこで、contextに付随する条件を明示的にするのに便利
  • 期待する結果がruby的なrueの値の場合、be以降を省略できる→expect(true).to be
  • be_truthyとか be_falsy とかもある
  • scala checkについては「テスト対象の関数への入力を(ある一定の境界内で)ランダムに生成して、境界値テストを自動化してバグを洗い出す手法」→テスト対象として興味ないデータをランダム値にするのとは意味が違う

結論

私が担当しているプロジェクトのテストコードは下記のように書くことにします。

describe 'hogehoge?' do
  context 'humuhumuが0のとき' do
    it { expect(piyo.hogehoge?("HOGE")).to be_truthy }
  end
end

letは使いこなせる気がしないので、使いたい!という場面が出るまでは使わない感じにします。

最後に

他にもこんな書き方があるよー!などのご意見やアドバイスがあればうかがいたいです!

先輩方、ありがとうございました🙏

参考サイト

メモ:2次元配列の行列を入れ替える

自分用のメモ。
理解を補助するために作成。

参考サイト:
ワクガンス | JavaScriptの覚書

参考コード:

function transpose(a) {
  return Object.keys(a[0]).map(function (c) {
    return a.map(function (r) {
      return r[c];
    });
  });
}   

※参考サイトより引用


Object.keys(array) で2次元配列の添字を返す。
これが変換後の行の添字になる。

var array = [[部門コード, 1000.0, 2000.0, 3000.0, 4000.0], [ほげ, 1.0, 4.0, 7.0, 10.0], [ふむ, 2.0, 5.0, 8.0, 11.0], [ぴよ, 3.0, 6.0, 9.0, 12.0]];
console.log(Object.keys(array)); // console: [0, 1, 2, 3, 4]

参考:
Object.keys() - JavaScript | MDN


mapの中でmapを実行すると、2次元配列がかえる。


最初に変換後の行の添字を取り出したのは、縦に読んでいくため。
各行の0番目の値を取り出した配列を作る、行の1番目の値を取り出した配列を作る…を繰り返して、新しい2次元配列を作成。

f:id:maetoo11:20170510122601p:plain

f:id:maetoo11:20170510122947p:plain


納得ヽ(=´▽`=)ノ

DockerでRedmineを動かす

概要

自分のMac Book ProでDockerを使ってRedmineを起動させるところまでやってみた。
(とりあえずやってみた系の記事)

portの指定に注意。

手順

Docker for Macをダウンロード&インストール

f:id:maetoo11:20170220125316p:plain

起動して「Docker is running」になっていることを確認。

コンソールを開いてdockerコマンドが使えることを確認。

$ docker -v
Docker version 1.13.1, build 092cba3

Redmine用のDockerイメージがあるかを確認。

$ docker search redmine
NAME                               DESCRIPTION                                     STARS     OFFICIAL   AUTOMATED
redmine                            Redmine is a flexible project management w...   369       [OK]
sameersbn/redmine                                                                  232                  [OK]
bitnami/redmine                    Bitnami Docker Image for Redmine                14                   [OK]
74th/redmine-all-in-one            Redmine includes hosting SVN & Git , backl...   9                    [OK]
vpetersson/redmine                                                                 2                    [OK]
eeacms/redmine                     EEA Redmine docker setup                        2                    [OK]
inspiredgeek/redmine-alpine        Simple Docker images to run Redmine tracke...   2                    [OK]
commonms/redmine                   Docker image for Redmine.                       1                    [OK]
fjudith/redmine                    Dockerized Redmine based on redmine:3.3 of...   1                    [OK]
starfox/redmine-plugin-dashboard   A container designed to install redmine-da...   1                    [OK]
puffinrocks/redmine                Redmine - project management and issue tra...   0                    [OK]
zhusj/redmine                      Customized Redmine                              0                    [OK]
openfrontier/redmine               Redmine docker plus the agile plugin.           0                    [OK]
ppschweiz/redmine                                                                  0                    [OK]
liumiaocn/redmine                  redmine alpine image                            0                    [OK]
thiagorider/redmine                Redmine Docker Image Automated Build Repo.      0                    [OK]
honsiorovskyi/redmine              Official Redmine + Git + Mercurial              0                    [OK]
abcfy2/redmine                     redmine docker image forked from official ...   0                    [OK]
thooams/redmine                    Fork docker redmine                             0                    [OK]
tukiyo3/redmine                    redmine                                         0                    [OK]
mikroways/redmine                  redmine passenger image                         0                    [OK]
miko2u/redmine                     Redmine                                         0                    [OK]
enderson/redmine                   Dockerized Redmine application                  0                    [OK]
shiratamag/redmine                 openshift redmine test                          0                    [OK]
speed/redmine                      Redmine                                         0                    [OK]

今回は公式のRedmineイメージを使います。([OFFICIAL]が[OK]になっているもの)

$ docker pull redmine
Using default tag: latest
latest: Pulling from library/redmine
5040bd298390: Pull complete
596ec0bfbfe7: Pull complete
330c0f0b9895: Pull complete
759aaf3bf184: Pull complete
44da9d770a4e: Pull complete
a9b8139f979b: Pull complete
e10cd3a7c32c: Pull complete
7a316ad832a5: Pull complete
aeacba04b652: Pull complete
45ac9e0e8f38: Pull complete
5fca085ddfc6: Pull complete
969036701fdc: Pull complete
a08e120d50ea: Pull complete
d26197c612f3: Pull complete
cf0ff0b2dba2: Pull complete
Digest: sha256:e59bcba1a77fe25c84ee7d536ff6e23ded685846cfa91e4c02854d57391a52de
Status: Downloaded newer image for redmine:latest

Dockerを起動する。
※-pはローカルとDockerのポートの紐付け。これをやらないとアクセスできない。

$ docker run -p "3000:3000" redmine

warning: missing REDMINE_DB_MYSQL or REDMINE_DB_POSTGRES environment variables

*** Using sqlite3 as fallback. ***

Fetching gem metadata from https://rubygems.org/..........
Fetching version metadata from https://rubygems.org/..
Fetching dependency metadata from https://rubygems.org/.
Using rake 12.0.0
Using i18n 0.8.0
Using json 1.8.6
・・・(略)・・・
Using rails 4.2.7.1
Bundle complete! 32 Gemfile dependencies, 56 gems now installed.
Gems in the groups development and test were not installed.
Bundled gems are installed into /usr/local/bundle.
/usr/local/bundle/gems/htmlentities-4.3.1/lib/htmlentities/mappings/expanded.rb:465: warning: duplicated key at line 466 ignored: "inodot"
/usr/local/bundle/gems/htmlentities-4.3.1/lib/htmlentities/mappings/expanded.rb:465: warning: duplicated key at line 466 ignored: "inodot"
== 1 Setup: migrating =========================================================
-- create_table("attachments", {:force=>true})
   -> 0.0053s
-- create_table("auth_sources", {:force=>true})
・・・(略)・・・
== 20160529063352 AddRolesSettings: migrated (0.0014s) ========================

/usr/local/bundle/gems/htmlentities-4.3.1/lib/htmlentities/mappings/expanded.rb:465: warning: duplicated key at line 466 ignored: "inodot"
[2017-02-19 14:40:57] INFO  WEBrick 1.3.1
[2017-02-19 14:40:57] INFO  ruby 2.2.6 (2016-11-15) [x86_64-linux]
[2017-02-19 14:40:57] INFO  WEBrick::HTTPServer#start: pid=1 port=3000

これで localhost:3000にアクセスして、Redmineの画面が表示されればOK

エンジニア交流会のススメ

この記事はSupership株式会社 Advent Calendar 2016の25日目の記事です。

私はSupershipの社員ではありませんが、グループ会社のSocketという会社の社員です。
Supership株式会社 Advent Calendar 2016企画者の @astapi さんからお誘いいただき、参加することになりました。

概要

  • エンジニア交流会はいいぞ
  • 会社・チーム・使っている技術などなど、いろいろなエンジニアが集まると面白いぞ

エンジニア交流会とは?

いろいろな会社・チームのエンジニアが集まって発表しあうイベントです。
今までにSyn.、Supsership、AppVador、Connehito、Socket、medibaのエンジニアが参加しています。

2ヶ月〜3ヶ月に1回のペースで開催していて、この記事を書いている時点で4回開催しました。

社内のエンジニアが集まって「勉強会」を開催している話はよく聞きますが、私たちが開催しているのは「交流会」です。

何かを学ぶという堅苦しいものではなく、技術的な話題に限らず興味のあることを発表し、お互いのことを知ってほしいという想いで開催しています。

実際、技術系のLTだけでなく深圳のスマートシティの話や、各社CTOを集めたぶっちゃけパネルディスカッションなど、コンテンツの幅も広げています。その話を肴に、懇親会では社やチームをまたいでエンジニア同士が交流しています。

f:id:maetoo11:20161225233825j:plain

背景

@yamaz さんと @inayuta さんの「何かエンジニアで集まってやりましょう」という雑な発言から、エンジニア交流会は始まりました。

ただ、この2人に任せていても話が進まない危険性があります。私自身はこの人たちのように、すごく尖った技術を持っているわけではありません。ですが、みんなの苦手な日程調整・事前準備・書類作成などは得意なので、自分ができることで貢献したいという想いで実行委員長を務めることにしました。

当時は社内にどんなエンジニアがいるのかも分からない・そもそも需要があるのかも分からないという状態だったので、「まずはゆるく開催してみよう」と考えていました。

実際に第1回を開催してみると、参加者数は30名超え、事後アンケートでも好評だったので、今でもゆるく継続して開催しています。
12月に開催した第4回のエンジニア交流会では、50名以上の参加者が集まりました(∩´∀`)∩ワーイ

運営のポイント

  • 準備はちゃんとする(場所・予算・社内調整など)
  • 仲間を見つけて準備や運営業務を分担する
  • メインコンテンツだけ事前にお願いしておくと良い(集客しやすい)

人を集めるので、集まった人たちが困らないように事前準備や社内調整はきちんとしておいたほうがいいと思います。
また、懇親会を開催するのであれば、参加者から費用を集めるよりも、会社からお金を出してもらって飲食物を準備するほうが楽かもしれないですね。
私達の会社ではこのイベントについて、会社側が費用を負担してくださっています。(いつもありがとうございます)

f:id:maetoo11:20161225235206p:plain

↑これは会場設営が完了したタイミングの写真です。

まとめ

いくつかの会社がくっついたり、子会社になったり、事業部ごとにチームが分かれてしまったり。優秀なエンジニアは集まっているけど、交流がないという組織もあると思います。

「エンジニアが大勢いるけど他チームがどんな技術を持っているのかわからない」「子会社があるけどまったく交流がない」という状況にモヤモヤしている方は、人を集めてゆるく「エンジニア交流会」を開催してみてはどうでしょうか。

実は私は、自分の所属している会社が子会社化されることに良いイメージを持っていませんでした。
しかし、エンジニア交流会を通して、違う文化・技術を持ったエンジニアたちの話を聞いたことにより「私の知らない面白いがそこにあるじゃん!」と前向きにとらえることができるようになりました。

この記事を読んだあなたもエンジニア交流会を開催して、「自分の知らない、誰かが知っている面白いこと」でワクワクしてみては?


いつもありがとうございます🙏

  • 実行委員のみんな
  • 広報、人事、総務のみなさん(取材協力、事前準備サポートなど)
  • 登壇者のみなさん
  • 参加者のみなさん