コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

Railsの複数形、単数形のルールを知りたい場合はrails/activesupport/lib/active_support/inflections.rb を見ると良い

Rails Tips

Modelは複数形に、みたいな情報のベース定義。

環境

$ bin/rails -v
Rails 5.2.2

前提

Railsの単数形、複数形、例外は登録することができる。

  • inflect.pluralは複数形への変換を定義
  • inflect.singularは単数形への変換を定義
  • inflect.irregularは単数形と複数形で規則性がない変換を定義(person/peopleみたいの)
  • inflect.uncountableは不加算名詞を定義（informationとか）

見る場所

rails/inflections.rb at master · rails/rails

module ActiveSupport
  Inflector.inflections(:en) do |inflect|
    inflect.plural(/$/, "s")
    inflect.plural(/s$/i, "s")
    # (中略)
    inflect.singular(/s$/i, "")
    # (中略)
    inflect.irregular("zombie", "zombies")
    # (中略)
    inflect.uncountable(%w(equipment information rice money species series fish sheep jeans police))
  end
end

こんな感じである。しかしzombieって…🧟

参考リンク

『表参道.rb #44 〜Ruby/Railsパフォーマンス〜』に行ってきたよあっさりメモ

行ってきたメモ

実は行きたかったけど全然行けてなかった表参道rb、途中着席だけど 表参道.rb #44 〜Ruby/Railsパフォーマンス〜 - connpass に行ってきました。

ざっくりLT感想

  • パフォーマンスチューニングの話だったので負荷対策した話とかActiveRecord周りの話とか聞けてよかった
  • キャッシュまわりの話から聞けたんですが、キャッシュは結構麻薬というか、キャッシュを主体にしたアプリケーション設計になるので勘所が必要になってくる
  • どんだけプロセスが必要になるとかの皮算用って普段しないし、結構いざ窮地に陥ったときにしかしないので難しい。検証環境ほしい。
  • includesの話、割と使われるがバッドノウハウはあんまり聞いたことなかったので伝承するには良い事例
  • Rubyのパフォーマンスも3.0でアップするので期待が！

見つけた本日のLTスライド

speakerdeck.com

github.com

勉強会全体の感想

  • Railsでのおつらい軽減税率の話とか、つらかったコードづくりの話とかを懇親会でしてた
  • 帰りがけスクラムの話をしたりしていて盛り上がった、計測凄技テクニックを垣間見た感じ…
  • 来月も参加したいし、ちゃんと最初からみたい…

『1チームスクラムと大規模スクラム（LeSS）ではPO目線で何が変わるのか？』に行ってきたよメモ

行ってきたメモ

LeSS,そういうのもあるのか！ということでチームスクラムと大規模スクラム（LeSS）ではPO目線で何が変わるのか？- POStudy ～アジャイル・プロダクトマネジメント研究会～ に行ってきたメモ

LeSSの概要説明

Youtubeの紹介動画を見ながらポイントごとの説明がありました。

www.youtube.com (日本語字幕があるのでONでどうぞ)

動画を流しながらの解説メモ

  • LeSSは一つのチームで行われるスクラムを複数のチームでどうしたらやれるの考え方なのでLeSSは可能であればやるべきではない。LeSSは2チーム以上のスクラムをどうやるか、従来のスクラムのエッセンスをどうそこに落とし込んでいくかの考えかた
  • 従来のスクラムと同様にちゃんとビジョンなどは明確に示す
  • 基本的には1つのバックログ、1つのプロダクトオーナー、同一のスプリント期間でやるのが前提
  • プロダクトバックログはチームに配分して、チーム間の調整ごとはPOではなく、チームそのものがコミュニケーションをし解決する。POやスクラムマスターがチーム間の調整に立つという考えではない
  • POは開発と顧客の要望を持つ人達の距離感を縮めていくことが仕事となる。そこが近づけば作るものは明確化されるのでPOが細かく支持を出さなくても良くなる
  • 8チーム以上を扱う場合は、LeSShugeという形になり、チームごとにAreaPOとAreaスクラムマスターができて細分化される。チームとしてはAreaPOがPOの立ち回りをし、チームはAreaPOをPOとして見るようにする。
  • LeSSはコンポーネントごとのチーム（UIチーム、サーバサイドチーム）ではなくFutureごとにチームを分けるべきとされている。
  • 極力シンプルなもので維持していくのがコアな考え方。
  • 規模の大きい組織のように部署で責任を負わせる形（例えばQA部門がいれば、品質の管理はその部門）みたいな考え方をするのではなく、チームがすべての責任を負う形にする
  • LeSSは大きなチームでもシンプルなスクラムをやるための取り組み方。

ディスカッション

フィッシュボウルの形式でディスカッションがあったのですが、部分的によりぬきメモです。

異なるチーム感で、プロダクトオーナーからのインプット情報はどの程度共有すべきか

  • 曜日を決めてその日はMTGの日としチームメンバー全員でスプリントレビューをやっていくなどの事例の話があった
  • LeSSとしては一つの大きな部屋にチームごとにブースを設けてレビューして回るバザールという手法がある紹介があった
  • 派生してコードをどうするかという話もあったが、コードはなるべくチーム内では属人化させないようにする、LeSSとしてはみんなが見てわかるコードを書くなどの話があった

どういう人がLeSSのPOに向くのか

  • 完璧主義者は向かないのでは？という意見
  • 意思決定をちゃんとするひと、やる/やらを明確にする人が強そう、など
  • 上記に関連して、ビジョンがはっきりあると意思決定が早い。そういうプロダクトのほうが筋が通って生きる。最終的なプロダクトの成長につながる。という意見もあった。

POはどうやってスポンサーを納得させるのか

  • 継続的に動く状態を維持していったりすることが大事
  • 内部でイマイチな評価でも、世に見える形になったら評価されて会社内の評価が変わったという話もあった

組織構造を変化させるにはどうすれば

スクラムはチーム、評価は個人、そこをどうしているのか

  • 多面的に評価するというご意見
  • スクラムなので計画性のあるもの、計画性のないものがあるので、計画性があるものはちゃんと遂行できたかを見て、そうでないものは動きなどを評価する

全体を通しての感想

  • ディスカッションのときにPO練度高い人の意見がたくさん出てきて自身のいるところとの練度の差を感じた
  • なんちゃってスクラムマスター業をやっているので、その観点から見ても学びはあった
  • 大規模スクラムといえども基本ラインを踏襲しつつの拡張なので、ベースのスクラムをしっかり身につけないとなんか要点抜け落ちそうなので、そこを理解するのが先かなという感じだった
  • フィッシュボウルで登壇したかた結構鮮烈なイメージの人多くて、中でも曜日固定でMTGデーにして残業禁止にしている事例がセンセーショナルだったのでもっとお話聞きに行けばよかったなという後悔…

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

GithubのIssueの編集は履歴に残るし、diffも見れる

Tips

めっちゃ便利やんということで一口メモ

Issueに下記のようなに「edited」で履歴が展開される

f:id:shinkufencer:20190305230302p:plain

履歴のうちのアイテムを1つタップするとdiffが表示される。すごい。

f:id:shinkufencer:20190305230415p:plain

チェックボックス系のdiffも残るので、なんかチェックリストをIssueにしてチェックの履歴を見るとかもできる。夢が広がる。

参考リンク

RubyのStringリテラルのfrozenはプラス演算子で解除できる

Ruby Tips

あ、こんな書き方あるんだっていうメモ

出典

実例

freze_text = "hubuki"
#=> "hubuki"

# freezeで凍結
freze_text.freeze
#=> "hubuki"

# 代入しようとするとエラー
freze_text << "a"
RuntimeError: can't modify frozen String
  from (irb):3
  from /usr/bin/irb:11:in `<main>'

# +演算子をつけるとfrozenが解除される
+freze_text << "a"
=> "hubukia"

参考リンク

何故コードレビューはするといいのか、何故コードレビューは難しいのか

雑記

日曜なのでポエミーな雑記です。

何故コードレビューをやるのか

大きくは2つある

機能的な仕様を満たせているかのチェック

  • そもそもの機能要件を満たしているかのチェック
    • 書いたコードが要求仕様に沿ってなければ意味がない。
    • 機能要件におけるバグの有無もココらへんがチェック対象

システムの構造やソースコードレベルの品質のチェック

  • 非機能要件における問題点の発見
    • 機能を満たしていても、それにおいて他の機能を阻害するなどあってはならない
    • 機能の要件には含まれないが、提供するシステムとして問題があるものはないか（セキュリティホールや致命的なパフォーマンス低下など）
  • 変更および変化に強いコードであるかのチェック
    • ことWebアプリケーションにおいては作って終わりではなく、作ったアプリが常に変化し成長していく、そのような条件に耐えられる構造になっているか
    • テストコードが含まれるなど、継続的に変化できるだけの下地が整っているか

コードレビューの難しいポイント

『そもそもの機能要件を満たしているかのチェック』において

  • レビュアーが仕様をしっかり理解する必要がある
  • レビュアーがその機能の隠れたバグをおもんばかることができる必要がる
  • レビュアーが仕様を含めたコンテキストを理解して機能に影響がないかを感知できる必要がある

『非機能要件におけるバグの発見』において

  • 非機能要件なのでインフラ環境などに依存するバグがないか、アプリケーション全体をとりまくコンテキストを理解する必要がある。
  • セキュリティなど機能としては注視されないが、認識を誤ると問題となるようなものもあるので、それを見極める審美眼が必要になる。

『変更および変化に強いコードであるかのチェック』において

  • 短絡的に書かれたコードか、先を見据えて書かれたコードかを判断する審美眼が必要。
  • 変化に強い、ということを何か言葉をもって説明できる必要がある。
  • 利用されているプログラミング言語としておかしな記述を行っていないかを認識する必要がある。

関連リンク

SimpleとEasyを簡潔に説明したいときに見せたいスライド『SimpleとEasyは違う』

スライド・記事回顧録

スライド回顧録です。

speakerdeck.com

一人暮らしをして、ちょっとでも料理をする人は買う「めんつゆ」。めんつゆは万能であり、パスタと和えて炒めれば和風パスタができあがり、そばを茹でればつけ汁として使え、肉じゃがなどの煮物ではそれなりの味が出せる。そういう側面をソフトウェア開発におけるEasyにあてはめたスライド。

日本人だからこそわかる感覚だし、それを端的に示していてすごいなというスライドです。PHPerじゃなくてもぜひ読んでほしいし、Easyの良さ、Simpleで考えることの大切さを今一度噛み締めたい。

関連リンク