BLogみんなのウェディングのエンジニア。聴いたお話をまとめておく倉庫的な。話題の本だったので、さっと読んでみました。97ただし、転職してはいけないタイピングは明確に存在します。今の仕事がツライ、嫌になった、というタイミングです。これは転職が目的になってしまうから、だそう。同じ動機で転職するサイクルにハマるから、と書いてます。転職は自分の叶えたいことをかなえる手段にしましょう、ということだそうですね。共感性の高いコンテンツでフォロワーを獲得するP208共感をしてくれる、ファンのようなフォロワーをしっかり獲得していく。暮らし-Tipsこんにちは、寒い季節になってきましたね。お風呂大好きな櫻井(@KotaSakurawi)です。ワタシ、お風呂、好きです。2019」の21日目の記事です。技術-RubyonRailsども、櫻井広大です。enumについて書いてみようと思います。enumは使ってみると僕は便利だと思っているのですが、初学者からすると、一体これはどうやって使うんだ?とか、ちょっと抵抗があるなじゃないかと思ってましてそのハードルのようなものが取っ払うことができればと思って書いています。delegateがあります。こちらを使うと、メソッドチェーンをたくさん書く必要なく実装することができます。guideのリンクも置いておきます。ガイドdelegateの使い方いつも書き方を忘れてしまうため、まずは利用例から書きます。書き方としてはこのように書きます。@instance.aaaと呼べるようになると認識しておくとよいと思います。to:で書いた部分を省略できるというイメージです。@instance.aaaで呼べます。Profileクラスがあるとしましょう。profileを持っているとします。Profileにはnameカラムがあって参照できるとします。:profileend@user.profile.nameのように名前を呼び出したいケースがあったとして、毎回メソッドチェーンしたものを書くと冗長に感じますよね。nameメソッドを定義するとします。以下のようなコードになるでしょう。delegateです。@user.nameと呼び出すことが下記の書き方でも実現できます。:profileendより明示的かつ、短く書くことができました。インスタンス変数や定数へもアクセスが可能delegateする対象ですが、インスタンス変数へアクセスすることも可能です。to:@userまた、定数を参照することも可能。定数はそのままクラスメソッドのように呼び出せるのであまり使うケースは少なそうに思います。:NUMBERoptionオプションとして、prefixをつけることも可能です。:aaa上記のように書くと、メソッドを呼び出すときに以下のように呼び出すことができます。endのようにぼっち演算子をつけたメソッドを定義した感じですね。RailsのテスティングフレームワークであるRspecを利用する際の行数を指定して実行する方法があります。:10などのオプションを付与することで、その行のテストを実行することができます。Rspecの行数指定のメリット行数指定をするメリットとしては、テスト実行が早いことが一番のメリットかと思います。必要な部分のテストだけを行うため、結果が返ってくるのも早いですし、テストが通ったのかどうかという確認も早いです。E2Eテストである、feature_specやsystem_specは実行がかなり重く、1ファイル単位の実行を繰り返しているとあっという間に時間が経ってしまいます。このような重いテストを繰り返す場合は行数指定で必要最低限のテストだけ実行することが非常に効果的です。describeやcontext単位で指定してみよう例えば、下記のテストがあったとします。app/spec/test/test.rb上記のコマンドですべて実行されます。endendcontext単位で実行したい場合contextの行数部分で指定しましょう。囲まれたテストの実行はこんなコマンドです。以下の部分がテストとして実行されます。app/spec/test/test.rb:4といった具体の指定でOKです。Rspecの行数指定のテストまとめ行数指定をすることで実行速度の向上、生産性の向上が狙えます!ぜひ、利用してみてください。技術-RubyonRails双方間の関連付けで、異なるオブジェクトを参照しないように指定するオプション。同様のレコードを見る、のようなイメージ。以降は自動的に付与されるらしいが、関連付けにオプションが増えたりすると自動的につかないケースがある模様。:category上記のように、orderをかませたりすると効かなくなってしまう。option.ちなみにrubocopで怒られるエラーは上記。inverse_ofをつけて対応しましょう。参考こちらのqiitaがわかりやすかった。CAMPを読んだので感想and学びをまとめておきます。本誌の内容を抜粋しながら書きます。まとめ可視化をすることで、問題を早期検知できるようにする。成果を最大限にする責任をプロダクトオーナーがもつ。ソフトウェアをつくる上で本当に大事なことは何でしょうか?それはできたものを使って実際の利用者が便利になったりお金を稼いだりといった成果をあげることです。P.20成果を最大にするための方法の1種類。注意しなければならないのは、開発チームはスプリント計画で合意した内容を完了させることについては全力をつくす必要はあるものの、計画したことを全て完了させることは約束しているわけではないということです。完了が目的になると、何かがおろそかになったり、不足の事態が’発生した場合に残業したり、プロダクトにおける問題が発生することになる。ベロシティは、あくまでも守るべきポイントではなく、チームの状態を示すものの一部と捉えるのがよさそう。熱意のないひとがプロダクトオーナーだったら、どうなるんだろう?プロダクトオーナーがなんとなく思いついたことを実現するために、開発チームは数週間を費やすかもしれない。できあがったものをみて、結局やり直しになるかもしれない。どっちのしようにした方がいいかを考えて欲しいとお願いしてもなかなか明確な答えが帰ってこないかもしれない。そんなふうにプロジェクトの大事な時間やお金を使っていて大丈夫なはずがない。具体的に何かが足りなくて困っているのなら、スクラムチーム全体でどうやって補っていくかを考えて行けばいい。そもそも熱意を持っていないとしたら、それを補うのは一番難しいことなんだこれに通ずる部分があるかも。https://note.mu/lifeisbeautiful/n/na13cf6fffe8dP.50どれが重要か自分たちで順序をつけることで、自分たちが大丈夫だと思えるようにするんだ。自分たちで順序、優先順位を決めること。現場が決めることに意味がある。P.72スプリントレビューの目的けれど、デモする本当の目的は、実際に動くものを触ってみて、本当はどうするべきかを知ることなんだ。プロダクトを小さく試しながら、本当に価値のあるものへと磨いていく。大きな手戻りはできるだけなくす。ペーパープロトタイプも一種。P.132着手するべきか次のスプリントで実現したいものは、実現しても大丈夫だという確信がプロダクトオーナーにあって、開発チームに必要なことを伝えられるようになっていないといけない。開発チームも、これなら実現できそうだと判断できないといけない。223スクラムスクラムは問題をみつけやすいやり方なんだな。プロジェクトの問題を見つけられるのは、実際にプロジェクトを進めていく現場の人たちだけなんだ。(1)スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。