インドカレーファンクラブ

パソコン、カメラ

ソビエトロシアの文学メモ

Муза

私の才は乏しく、声も大きくはない、
だが私は生きており、私の存在も
この地上の誰かにとっては愛しいのだ。
はるか後の人々は、詩の中に
私のことを見出してくれるだろう。
誰が知ろう、私の心が
彼らの心と結びついて、
私が同世代に友を見出し得たように、
後の世代に読者を見出し得ないなどと。
 
E.A.バラティンスキー
https://twitter.com/kyuseisya_/status/1211890434609299457

 

Мой дар убог, и голос мой не громок,
Но я живу, и на земли мое
Кому-нибудь любезно бытие:
Его найдет далекий мой потомок
В моих стихах; как знать? душа моя
Окажется с душой его в сношенье,
И как нашел я друга в поколенье,
Читателя найду в потомстве я.
 
<1828>
Русские поэты. Антология в четырех томах.
Москва: Детская литература, 1968.
Евгений Баратынский - RUSSIAN POETRY

ロシア語のWikipediaが詳しい
Баратынский, Евгений Абрамович - Wikipedia

これは僕が大変気に入ってる詩で、僕が写真をせっせと撮る理由それそのもの
この詩を知ったときには喜んだものだった!
いつかこの詩を印刷して額に入れて家に飾りたい

Умом Россию не понять

ロシアは頭ではわからぬ
並みの尺度では測れぬ
ロシアならではの特質がある
ロシアは信じることができるのみ
 
フョードル・チュッチェフ
ロシアのアフォリズム5選 - RUSSIA BEYOND

 

Умом Россию не понять,
Аршином общим не измерить:
У ней особенная стать —
В Россию можно только верить.
 
Умом Россию не понять - Wikipedia

この詩を諳んじるとロシア人に喜ばれるらしい
日本でいう「春はあけぼの」みたいな

いつか役に立つ日がくるはずだ、と心に留めている詩だけど一向にその機会がこない
なんならこれがプリントされたTシャツを持っている

汎スラブ主義色

www.abysse.co.jp

赤:自由のために流された血
白:まばゆく輝く光明・清潔
青:澄みわたる空

※画像を貼るのがめんどくさいのでリンク先(引用元)を見ること

ロシアの国歌を聴く時にこれを知っていると音に深みが出る

恵比寿 住みやすさレビュー

恵比寿の狭いマンションに7年住んだ。で引っ越すのでレビューする

はじめに

恵比寿について、僕はいつも「交通的に便利だけど、所詮それだけ。」と言ってた

大人の街なんて呼ばれてたり、よくデートスポットが紹介されたりしていて...
でもそこは僕がヘヴィメタルのTシャツきて短パン履いて散歩するコースだよ。残念だったね

一方僕はデトロイト・メタル・シティの根岸(渋谷系が好きなポップミュージシャン志望だけどメタルをやっている)みたいな人間なので、 案外丁寧な暮らしが好きで、そこそこ気に入った街だったのだ......

いいところ

交通的に便利

超便利。文句一切なし。終電を気にしたことはほぼない

大船まで直通なので輪行して海まで行ったりも気軽

街が洗練されている

行きもしないカフェとか、行きもしないケーキ屋とか、そういうのがある街が良い
歩いていて楽しいし、活気が感じられる

そうでありながらも渋谷・原宿のうるさい雰囲気がないのは流石大人の街というところか...悔しいけど...

※この文章は三鷹の賃貸周辺を見に行った後に書いたもので、
 僕は三鷹の街の凡庸さ(チェーンばっか)、老人の多さに驚き、しょんぼりしたのだった......  若者文化は自分とは縁のないものだと思ってたけど、やっぱ大事だった

代官山駅が徒歩圏内

散歩するだけで楽しいし、渋谷まで出ずに東横使えるのは結構便利
代官山蔦屋書店には大量のCDを借りによく行った

土地柄、服屋も多くてセールに一回いって住所とか書いておくとセールの度にDMが届くようになって便利

中目黒も徒歩圏内

中目黒の居酒屋は恵比寿・代官山より気楽な感じが良い。まあ、それだけなんだけど

ついでに目黒も徒歩圏内だけどあんまり行く用事はないかな
カレー屋くらい

東京都写真美術館ほか展示スペースが徒歩圏内

ここまで文化的な意味での生活基盤が揃っていることは中々ないと思う

カメラ屋が徒歩圏内に2件

代官山のGTカメラ、恵比寿の大沢カメラ(現像もできる)
前者は行きつけ

実はカレー屋が豊富

これはどっか別で書きたいけど、実は美味しいカレー屋が豊富
前述の通り中目黒とか目黒にも美味しいところがたくさん!

自転車に乗ると色んなところに行ける

そりゃそうだけど、都心だから東西南北色んなところに行きやすい印象

  • 東は広尾、品川、六本木、頑張って銀座
  • 西は松濤、駒場
  • 北は渋谷、原宿
  • 南はちょっと頑張って自由が丘、頑張って多摩川

ここらへんにはよく足を運んだ

だめなところ

物価が高い

ピーコックストアの高さに辟易して広尾の肉のハナマサ、渋谷のライフまで買い出しに行ってた
ピーコックストアでさえ高いのに無駄に成城石井やザ・ガーデン自由が丘が駅ビルに入っている。バカか?

たまにバカがくる

僕が住んでいたのは閑静な住宅街だけど、まあちょっと歩けば居酒屋街なので迷惑な奴らがたまに迷い込んできて夜中に叫ぶ 山から出てくるな

周りのマンションの工事が多い

たまに気が狂うほどうるさい時期が続き、周りに何もない皇居に住みたくなる

名ばかりのラーメン激戦区

笑わせないでほしい。前述の通りカレー屋の方がいいよ

恵比寿横丁と相席屋

僕に言わせると恵比寿の汚点

恵比寿横丁が渋谷横丁として宮下公園に輸出された際の僕の落胆は計り知れないものだった

他、どうでもいいこととか

さいごに

恵比寿に住んだ僕から見た住みたい街は

  • 恵比寿
  • 広尾
  • 白金
  • 麻布十番
  • 代官山
  • 松濤
  • 駒場
  • 中目黒
  • 自由が丘
  • 田園調布

舌が肥えてしまった。なにより街には品位があるべきだと思う

恵比寿はなんだかんだでいい街だったと思う
部屋が狭くていい人、あるいは高所得者は是非住んでください

長い打ち合わせを短くするためにやったこと

はじめに(前提など)

打ち合わせが長くて、すごく辛かったので短くするために頑張った

チーム

僕のチームではスクラム開発をしていて、スプリントの期間は1週間

7人いて、2人は企画、5人は開発

週のスケジュール

まず前提として週のスケジュールはこんな感じ

以前それぞれのイベントにかかっていた時間と (今回の話で書いている努力の結果として)短くなった今の所要時間も書いている

イベント 頻度 予定時間 以前の所要時間 今の所要時間 備考
プランニング 週1 2h 3h 1.5h 短くなった!
レビュー 週1 1h 1h 1h
レトロスペクティブ 週1 1h 2h 1h 短くなった!
朝打ち合わせ(進捗報告) 毎日 15m 1.5h 15m 間延びしなくなった!
夕打ち合わせ(困ってること報告) 毎日 0.5h 0.5h 0.5h 報告内容に依る
突発打ち合わせ(仕様や実装の相談) 週2くらい 決まってない 0.5h ~ 2h ~ 1h 短くなった!

スクラムイベントとかの用語の雑な説明

  • スプリント:開発の期間。僕のチームでは1週間
  • プランニング:スプリントの期間にこなす作業の計画を立てる打ち上わせ
  • レビュー:スプリントの期間にこなした作業の報告を偉い人にして、フィードバックをもらう打ち合わせ
  • レトロスペクティブ:スプリントの期間の反省会

やったことの概要

基本的に施策をひたすら打ちまくることでヒットを狙っていった

以下にそれらを列挙するので参考にしてね

打ち合わせのルール、司会として頑張ることの2軸になっている

やったことの詳細

ルール編

チームのルールとして設けてみたこと

打ち合わせの司会なんてものは役割でしかなくて、本来誰かがやればいいし何なら毎回交代でもいい
誰でも司会ができるように(やりやすいように)ルールを構築しておくと良い

他所では暗黙の状態で成立しているであろうモノ(率直に言うと程度が低いモノ...)も多いと思う。正直

会話を被せるのを止めてもらう

喋りやすくなるから

残念ながらうまく定着しなかった

打ち合わせの際に口頭で話を整理しない。テキストエディタに書き出し画面共有する

文章で捉えたほうが絶対に分かりやすい
っていうか社会人なら打ち合わせ中にメモくらいとるでしょ、ということでそれを画面共有する

  • 頭がいい人は時として論理が飛躍するのでその対策
  • 話についていけない人の救済手段
  • そのまま議事録にもなる
  • 実装の話とか書いておかないと忘れがち
  • 複数人が同じメモをとる手間が省ける

書き出しは自然言語に堪能で、要約・構造可がうまい人がやるといい

※新卒で入ったSIerにいた時は50歳くらいのベテラン部長がやっていた
 辞めた今思えばあの人の書き出しは非常に優れていたし、巨大なプロジェクトを束ねる素養の一部は間違いなくそこにあった

打ち合わせの議題・所要時間、資料を事前に共有する。必要に応じ打ち合わせの前にコメントを投げておく

打ち合わせ直前の資料共有はよしとしない。前もって回覧させる

「持ち帰って確認します」をなるべく事前に解消する

打ち合わせを行う前に共有の場か議論の場か明確にする

共有の場では極力議論をさせない
上に書いたとおり論点はなるべく打ち合わせ前に処理しておく

逆に考えると議論の場ってのはあんまりなくて、実装の相談とかブレストとかになるかな

場の区切りを明確にする

打ち合わせから打ち合わせへのナアナアな移行を許容しない

必ず打ち合わせ一つ一つを打ち切ってから別の議題に進む

例えば「一旦、朝の定例はこれで終わります。続いて定例で出た実装の疑問点についてですが~」

いちいち打ち合わせの場を設けない(打ち合わせにしない)

急いでない場合には打ち合わせじゃなくてチャットだとか、資料の回覧+コメントで済む場合が多い
前述の「打ち合わせの議題・所要時間、資料を事前に共有する。必要に応じ打ち合わせの前にコメントを投げておく」を進めていった延長線上にあるルールかも

打ち合わせをすると元の作業から打ち合わせに移って、その後元の作業に戻って...と切り替えの手間が発生するというのもあるし(まあこれは打ち合わせタイミングの調整で多少マシになるけど)

※とはいえ、これはチームによってはNGかも、というかアジャイルソフトウェア宣言の以下の内容に反している

情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 https://www.ipa.go.jp/files/000065601.pdf

個人的な意見だけど、僕は優れた日本語文章は発話より遥かにまともに情報を伝達すると思っている。適切に日本語が書ければ誤解は生まれにくい。うまくやらないとスピード感はあんまりないかもしれないけど

打ち合わせの決定事項・次のアクションを整理する

新卒みたいな程度の話なので割愛

司会としての努力編

場を仕切るというのは骨が折れるけど、どうしても必要になってくる

僕のチームでは一旦技術を集約させるため司会を二人に固定した

沈黙をなるべく作らない。次に進む

以下のようなシーンが多々ある

「ではこれでいこうと思います。問題ないですか?」
「(...沈黙...)」
「いいですか?」
「(...沈黙...)」

こういう時には沈黙を合意に捻じ曲げる

「では特に異論がなければこれでいきます。問題ないですね?」
「(...沈黙...)」
「ではこれ決定します」

一旦雑に合意しても本当に問題がある場合には「ちょっと待って」とか「(後からになって)そういえばさっきの箇所だけど...」と言ってもらえる

適当な人に「**さん、これで大丈夫だよね?」と聞いてしまってもいい
とはいえちょっと抜き打ちテストみたいになって心苦しさもある

そもそも沈黙しないでよ。と思わないでもない
「人が話していたら頷くなり相槌を打つなりしろ」と僕は少なくとも小学生の時には教えられた

関係ない話が長くなりそうだったら切る

例えば進捗報告の場で難しい実装の話をし始めたら切る

「それ長くなりそうなので後にしましょう」

これを言えるようになるまでなかなかに心労が...

論点のズレに敏感になる

議論が白熱してきたらチームメンバーに喋らせておいて、静観・整理してみる

たまに論点がズレていたり、論点が2つに分裂していたりする

「申し訳ないですが論点ズレてきている気がします。課題は**ですよね?」

これを言えるようになるまでなかなかに心労が... part2

問題が不透明な状態で問題について議論させない

論点のズレに近いかも

例えば、こういう話があったりする

「さっきの会議の中で出た話でAの案件で仕様変更が発生しそう!明日にはわかりそうだけど...」
「明日から着手するBの案件のタスク色々積んでるけど仕様変更の規模が大きいとマズイ!」
「A, Bの作業の優先順位どうする?Bのスケジュールずらさないといけないんじゃない?!」

ここでいう「不透明な問題」は案件Aの仕様変更の内容
それが確定しないまま、それについての話をしたところで当然フラフラした話にしかならない

なので問題の内容が不透明な状態でその問題について議論させるべきではない
※因みに上の例では、話の翌日に仕様変更の規模も小さかったことが判明。全くの杞憂だった

でも、のっぴきならない状況であれば、仮説に基づいて複数の対応パターン考えることになるとは思う

説明を人に委譲する

何でもかんでも司会が喋ればいいわけじゃないので、ある話題について得意な人がいたら任せる

当然といえば当然の話

打ち合わせが長引いてきたら圧をかける

「そろそろお腹が空いてきたので結論を出したいところですが...」

打ち合わせをきちんと終わらせる

だらだら次の話次の話と続いてしまう場合が多い(Slackで済む話が多い)
そういう時は無理やり切る

「あ~~!時間です!時間なのでこの打ち合わせはここまで!ではお疲れ様でした!」

いつも喋りにくそうな人がいたら別途理由を聞く

公の場だと激詰めみたいになりそうだったらコッソリ聞いてみてもいいかも

そういう人に限って案外話をまとめられたり、いい疑問を出してくれるのでなるべく改善を図る
その人のためだけではなく人的リソースを利活用するという意味で

打ち合わせが長いという共通認識をもつ

「打ち合わせ長いよね?!」とコッソリとチームメンバーに聞いてみる

共通認識を確認した上で「僕が打ち合わせを短くするよう頑張ります」と伝えておけば当事者意識を共有できる(巻き込める)

おわりに

人間は自由すぎるし中身に個人差があるので基本的にルールで縛ったほうがいい
ルールは人間を補ってくれる

打ち合わせ時間が短くなってから、「前は打ち合わせが憂鬱でした」みたいな話が出たりする
頑張った甲斐があったなぁ...(でも憂鬱だったなら行動起こしてよ!)

【Go】sqliteとsqlxをおためしするだけ

概要

おためし用コード

テーブルをSeletctしてEntityにマッピングしたり、その時にフィールドにEnumがあったり、
EntityをそのままInsertしたり...

そういうのを一応動かしてみたかった
ついでにsqliteもお勉強のために使う

というコードを書いたのでせっかくだからのせる

sqlxの使い方は公式のreadmeみたほうがはやい

GitHub - jmoiron/sqlx: general purpose extensions to golang's database/sql

DB系ライブラリでどれ使おうか迷ってsqlxにした話も書きたい気持ちはあるけどまとめサイトみたいな感じにしかならないからまあいいか

構成

  • main.go
  • test.db(sqliteが作ってくれる)
  • enum
    • member_type
      • membertype.go

enum周りのフォルダ構成は...どうするのがいいかな

コード

よめば分かる

main.go

package main

import (
    "fmt"
    "log"
    membertype "sqlite_sqlx/enum/member_type"

    "github.com/jmoiron/sqlx"
    _ "github.com/mattn/go-sqlite3"
)

// Driver
// go get github.com/mattn/go-sqlite3
// sqlx
// go get github.com/jmoiron/sqlx

const dbPath = "./db.sql"

const initQuery = `
DROP TABLE IF EXISTS members;
CREATE TABLE members (
  id INTEGER NOT NULL PRIMARY KEY,
  name VARCHAE(20) DEFAULT '',
  type INTEGER DEFAULT NULL -- 1:Human, 2:Beast, 3:Elf
);
INSERT INTO members (name, type) VALUES ("ペコリーヌ", 1);
INSERT INTO members (name, type) VALUES ("コッコロ",   3);
INSERT INTO members (name, type) VALUES ("キャル",     2);
`

type Member struct {
    ID   int                   `db:"id"`
    Name string                `db:"name"`
    Type membertype.MemberType `db:"type"`
}

func main() {
    // ドライバ名 + データソース名(なかったら作ってくれる)
    db, err := sqlx.Connect("sqlite3", "test.db")
    if err != nil {
        log.Fatalln(err)
    }

    // テーブルだけつくる
    db.MustExec(initQuery)

    // データ入れる
    chris := &Member{
        Name: "クリスティーナ",
        Type: membertype.Human,
    }
    transaction := db.MustBegin()
    transaction.NamedExec("INSERT INTO members (name, type) VALUES (:name, :type)", chris)
    transaction.Commit()

    // Select
    members := []Member{}
    err = db.Select(&members, "SELECT id, name, type FROM members")
    if err != nil {
        log.Fatalln(err)
    }

    // 見てみる
    for _, member := range members {
        // Typeは型がMemberTypeでそれらはString()メソッドを実装してるのでいい感じに出してくれる
        fmt.Println(member.ID, member.Name, member.Type)
    }
}

// 出力
// 1 ペコリーヌ ヒューマン
// 2 コッコロ エルフ
// 3 キャル ビースト
// 4 クリスティーナ ヒューマン

membertype.go

package membertype

type MemberType int

const (
    _ MemberType = iota
    Human
    Beast
    Elf
)

func (t MemberType) String() string {
    switch t {
    case Human:
        return "ヒューマン"
    case Beast:
        return "ビースト"
    case Elf:
        return "エルフ"
    case 0:
        panic("Unknown")
    }
    panic("Unknown value")
}

『カイゼン・ジャーニー』感想

kaizenjourney.jp

公式サイトを見ると登場人物が絵になっててカワイイ!

会社で借りて読んだのでその感想というか、気に入ったとこのまとめ

気に入ったとこ

チームのWorking Agreementを決める

Working Agreementというのはチームの価値観・行動規範という感じのもの
取り決めとかルールって言ったほうがわかりやすい

僕はこの考え方が好き。人間はルールで縛ったほうがいい
でもルールを増やしすぎるとそれが軽い内容でも嫌がられるので難しい

試しにググったら良い取り組みをしている例があった

blog.engineer.adways.net

許可を求めるな謝罪せよ

何かの取り組みを始める時の話として、失敗を恐れず小さなところからやれ!という話が気に入った

「許可を求めるな謝罪せよ(It is easier to ask forgiveness than permission.)」という言葉を胸に。まずは"小さく試みる"ことだ。

いざ新しいことを始めるにあたっては、小さく試みることからスタートすることが大切です。大がかりに始めてしまうと、うまくいかなかったときに失敗の影響が大きくなってしまいます。

僕のチームでは最初から完璧を求めすぎるので、こういうことを大事にするべきだ(後述)

なぜチームで振り返りをするのか

僕はそもそもスクラム開発のチームでの振り返り(レトロスペクティブ)に懐疑的で、
「反省・改善ができる人間は一人でするし必要に応じてチームに展開もできるし、何故わざわざ全員でやるのか?」とか思っていた
(まあ、今でもまだそう思っている節がある)

というところでこの話は多少いい薬になった

そうか、他の人に気づかせてもらうんだ。自分で気づけないのはどうしようもない。だから、他の人に気づかせてもらう仕組みにしないといけないんだ。 自分の経験や思考だけだと、自分自身が限界になる。でも、他人の経験や思考を活かす仕組みにすれば、自分の限界は越えられる。

こう考えるとチームの振り返りは他人の動きに対してもっとバシバシ意見が出るような形である方が有意義 エンジニアはキツいこと言いがちなので難しいけど

失敗を積み重ねる

頻繁に変わる時代のニーズや市場の変化など、不確定要素が多々ある今日のソフトウェア開発では、プロダクトやプロセスをチームでふりかえりながら、 継続的にカイゼンていくことが、より良い選択といえる。その際、Fail Fast(早く失敗する)の精神が、漸進的に開発していくことの後押しになる。

僕のチームではチームとしての取り組み・チャレンジを決める(やるんじゃなくて決めるだけ)にも最初から完璧を求めすぎるきらいがある 振り返りの時間がが最たる例でそこで異様に討論して時間をかけすぎだ。というのが僕の意見 ※僕は完璧を求めすぎないという説もある

コードとしてのプロジェクトの根幹の設計とか、そういうとこは徹底的に最初から練るべきだけど そうじゃないところはさっさと試行してダメだったら変える、くらいの方が気が楽だと思う

何のためにアジャイルでやってるの?ウォーターフォールでやりたいの?とかたまに思う

越境する開発チーム

開発チームもプロダクトオーナーも互いの役割を学んでいこうね~、という話

役割を学ぶというと、ハイ学んだ終わり~って感じになりそうだけど、そういうことじゃなくて、
そもそもエンジニア以外にはわかりやすい言葉使うとか、そういう心掛けをこう...と僕も思う

スクラムマスターは役割

スクラムマスターは、役職でも専任でもなく、単なる役割ということを忘れてはならない。

内容はググれば出てくるだろうからいいか

アジャイルな見積もり、アジャイルな計画づくり

初期フェーズで長い期間をかけて、使えない緻密な計画を作成するよりも、現場で活用できる使える計画づくりをし続けることが重要なんです。

初期のリリース計画は、作成したら完成ではないのです。スプリントごとに毎回リリース計画を修正するといっても過言ではありません。むしろ積極的に変更するためにつくっていくのです。

僕のチームではプロダクトオーナーから「いつリリースできるんですか!」と詰められることがあるんだけど、
そもそも当初スケジュール立てた後、ろくに修正してなかった(そりゃわからんわ)

でも修正するのめんどくさいんだよね

SL理論

ググれば出てくる

単純に知らなかったのでホ~と思った

leadershipinsight.jp

全体的な感想

本自体が物語になっててわかりやすい

カイゼン的な行為を取り組むスコープが個人から始まってチーム内、チーム外へ広げていくような流れで、アジャイルだのスクラム的な文化はそのためにある、という話がわかりやすい

偉い人の鶴の一声でいきなり「スクラム開発をするぞ~!」といって始まるようなチームのメンバーにとってはいい本だと思う
何を思ってスクラム開発を始めたかったのかが汲める

もっとも碌でもないことをいうと、「スクラム開発」という「よくわからんけど進んでるIT企業で流行ってるやつ」をチームに採り入れた結果開発効率が上がった!みたいな話が成立すると偉い人の評価が上がるんだろうな、とも
※マネジメントする職分にある人の目標にはチームの育成とかそういうのがある筈なので

レトルトカレーについて色々

はじめに

スパイスからカレーをつくるとレトルトカレーを軽視しがちな気がする
でも折角なのでレトルトカレーについても書きます
どうせこのブログでネタがなくなるなんてことないし

僕的には

そもそも量がないという理由で僕はレトルトカレーあんまり好きじゃないです

味の話をすると、スパイス系は美味しくないというか上辺の芳香だけで深みがない印象
一方で欧風のカレーとかバターチキンは結構よくまとまってる感じかな

まあなんだかんだカレーが好きだからとレトルトカレーもちょいちょい買うんだけど

商品メモ

好きなやつで覚えてるのだけ

宗谷産たこカレー

タコの旨味が!これは普通に自作カレーにも活かしたいね

www.saihok.jp

いなば食品 チキンとタイカレー(イエロー)

レトルトってか缶
うろ覚えだけどこれが一番美味しかった気がする

www.inaba-foods.jp

肉のハナマサ チキンレッグカレー

量が多いのが素晴らしい!500g!
昔は大好きだったけど今はもうちょい小難しい味のほうが好みかも
でも量多いから偉い

リバースエンジニアリング

を僕もしようと思っている

既にやってる人がいた

note.com

レトルトカレー買うのはどこがいいの?

僕も気になってたらいいところを教えて貰った

www.ace-group.co.jp

レトルトカレー界で著名な人

マツコのなんとかかんとかにも出てた
その活動はレトルトカレーに閉じていないのでレトルトにも強いカレーの人というイメージ

twitter.com

【Rails】じゃあどうやってRuby on Railsを習熟するのか。結論は出ていないけれど(しょぼ記事)

僕は以下のように思い悩む

  1. 別の(言語での)Webアプリケーションフレームワークは習熟している
  2. Railsチュートリアルをざっとやってなんとなく理解した
  3. 業務でRailsを書く
  4. いまの実装が最適なのか全くわからん

じゃあどうすればこれが解決するのか...

辛さ

僕より遥かにRailsが書けるお友達のご意見を勝手に引用

  • Rails 、「知ってるとめちゃくちゃ綺麗になるけど知らないとどう考えても書きようがないし調べるきっかけもない」みたいなの多くない?って思う
  • ちゃんとすべてを網羅的に知るための時間を充分取れれば快適、みたいなところがある感

うんうん。(SEOに強いブログではココで無駄に首肯している外国人男性の画像が挿入される)

僕の思う別の話:
例えば、Railsを完全に理解している人がプロジェクトにいれば、ソースチェックなり設計レビューなりでアドバイスを貰ってチーム内の習熟度を上げていくことができる

でもそういう人がいない場合はもはや全員が孤児
スクラム開発で期間が絞られる中では最適解を調べ尽くせることなく負債を積むこともあるし、 怖いことにその時は負債であることにすらも気づけない!誰も!

考えた

ということで何をすると良いのかなと一生懸命考えた
考えただけでまだ実行できてないけど...

  • ドキュメントを読む
    • 都度検索じゃなくて1回全部通して読んだ方がいいと思う(自戒)
  • ベストプラクティス・アンチパターンの知見の蓄積
    • 体系的にまとまっているものはなさそう?なので一生懸命調べるしかない
      以下のサイトは結構まとまってるかも
  • Railsを完全に理解している人をプロジェクトに投入

riptutorial.com