Practicing Rails

# Practicing Rails ## 第1回 ### 開催日 2022/10/31 ### 各自メモ - @shirotamaki - 序章、著者の本棚には多くの技術書がある。 - 電子書籍 = kindle - 目標1年以内？ - みなさんよろしくお願いします〜 - @Hikaru - がんばりましょう〜 - 英単語帳何かいいのないかな〜 - 英文解釈できると訳すのが楽になるな〜 - @uda - 一回読んだはずなのに案外忘れてた - 1年以内におわるといいな ### 決まったこと - 毎週月曜 20:00〜21:00 ### 今後決めていくこと - 祝日どうするか？ ### 次回 - “This is exactly how I felt learning Rails.”〜 --- ## 第2回 ### 開催日 2022/11/7 ### 各自メモ - @uda - 文法難しい - つらいのが楽しいみたいな感じなんだろうということがわかった - この人はプログラマーにとても向いてそう - introductionおわった〜 - @shirotamaki - three rules - わからないことはjustinへメールして質問する - ハードワークして壁にぶつかって挑戦を続ける。苦労した分得るものは大きい - Railsの学習を通して好きな分野を探せ。そして楽しめ - hikaru - プログラマーはマゾ - 楽しい領域を見つけたいですね〜 - 本文楽しみですね！ - 発音を練習する便利ツールです　https://youglish.com/ - ３か条 - あなたのせいじゃない。著者のせい。 - もがくこと、失敗すること、そして報いを受け入れよう。 - 楽しいことを見つけよう。 - 一億人の英文法、キク英文法 - Duo3.0 ### 次回 Chapter 1 Tiny Apps: The best way to study new Rails ideas --- ## 第3回 ### 開催日 2022/11/14 ### 各自メモ - @uda - What's the point of ~? = 何の意味があるの - get through - drain - wipe - 3ヶ月で52apps - やっぱりひとりで読み進めてたらきびしいだろうな - @shirotamaki - Rails Appsを50個作るハードルが下がってよかった。 - rails new にしてmodelが1,2個の簡単なAppを作ったり壊したりする分もカウントできる - 自作サービスを50個作れと言われたらキツいがこれなら可能だ - 技術書を読むなら手を動かして数をこなせということ - hikaru - 簡単に完全に動くアプリが作れるので作って遊ぼう！ってこと？ - 自作サービス案でYouTube埋め込み＋キーボード＋チューナーってのを思いつきました。ええ、しゃ○ーんのパクリです。 ### 次回コラム　What’s the difference between rails and bin/rails? --- ## 第4回 ### 開催日 2022/11/21 ### 各自メモ - @shirotamaki - 今日も輪読会にジョイン！ - bin/rails - https://qiita.com/jnchito/items/c5a0848144203dce6e26 ### 次回 - Using Rails to learn Rails --- ## 第5回 ### 開催日 2022/11/28 ### 各自メモ ### 次回 - Using Rails to learn Rails --- ## 第6回 ### 開催日 2022/12/5 ### 各自メモ - @shirotamaki - 決まったタイプの小さなアプリを作ること - 数をこなすこと - rails newしてからの冒頭の作業はほとんどん似ている - busywork(忙しいだけで価値のない仕事)で時間を費やしてはいけない。 ### 次回 - “But… scaffolds?” --- ## 第7回 ### 開催日 2022/12/12 ### 各自メモ @shirotamaki - even though - 〜であるのに、〜するのに - tear - 涙ではない - 引き裂く、破る、引き裂いて穴をあける - teardown 引き剥がす、取り壊す - prefer - 〜のほうを好む - bootstrap - ブーツのストラップから ### 次回 - “Where does the code go?” --- ### 開催日 2023/2/6 ### 各自メモ ### 今回 - "Testing the boundaries" 境界値テストこういう経験は今までにありますか？あなたはRailsの本について何か読んで考え始めます。一文や二文を読み込んで、質問で頭を埋め尽くされるでしょう。 - この方法で何で動くんだろう？ - どうやったらこれが動くというんだ？ - 私が習ったアイデアとは他のアイデアと一緒に使ったらどうなるでしょうか？突然、最後にいた場所を10ページほど過ぎてしまい、戻って全てを読み直さなくてはならない。もしくは、あなたはこのコンセプトについて十分に学んだと思っている、次のチャプターで迷ってしまう。これは私が技術本を読むときに起こることです。私はこれらの質問を解決することはできない。ほとんどのRailsの本と動画はあなたに何ができるかを示すには良い。しかしそれらは全てを説明できていません。それらのギャップが疑問を発生させて、あなたは自然にそれらの質問に答えてほしくなるでしょう。つまり、私が「学んだ何かについて修正したり動かしたりしてみましょう」と言ったときは、「学んだことに対して持った疑問にコードを使って答えてみましょう」ということを意味しています。ドキュメントを探したり、以前は知らなかった様々な設定やパラメータを試したりすることによって上記のことができます。すでによく知っているアイデアと学んだばっかりのことを一緒に使うことによって、あなたはそれらがどのように相互に影響しているのか見ることができます。壊すことによってもできますが、それは次のテーマでお話しましょう。何かが壊れたときのエラーメッセージを調べることや、何か新しいことを発見したときの達成感はあなたにずっと付いて回ります。これはただ本の章を読むだけに比べて、より気楽でずっと楽しいです。なぜなら考え方やアイデアは今やあなたのものだからです。 ### 次回 - 書記：hikaru --- ### 開催日 2023/2/13 ### 今回 - How can you break it?(p.30くらい) ### 日本語訳 #### How can I break it? 何かを学ぶときにそれを壊してみるというのは私のお気に入りの方法の一つです。例えば、Railsの`config_for`メソッドについて試しているとしましょう。こんな感じの見た目です： ```ruby Rails.applicaiton.config_for(:redis) ``` この行は`config/redis.yml`を読み込みます。もしdevelopment環境にいる場合、`config/redis.yml`の`development:`以下を探します。そのほかの環境にいる場合はそれに応じて変わります。そして`development:`以下のキーをハッシュとして返します。ここには質問に答えるための、実際に動かせるものがたくさんあります（日本語訳が怪しい）。文字列の代わりにsymbolを渡したらどうなるでしょうか？ファイル名ではなくパスを渡したらどうなるでしょうか？`lib/`にある`.yml`ファイルを読み込む方法はあるでしょうか？`/usr/local/etc/redis.yml`のような絶対パスを渡すことはできるでしょうか？`.yml`ファイルが定義されているRailsの環境についての設定を持っていないとしたらどうでしょうか？設定ファイルの中でERBを使うことができるでしょうか？次に、これらの中のいくつかを試してみて、何が起こるかみてみましょう。好奇心で何かを壊してみるとき： - 思った通り、さまざまなエラーを目にするようになるでしょう。これはとても役に立ちます：予め出ることがわかっているエラーを見てもあまり怖くないですし、メッセージを頻繁にみることになるでしょう。そして、それらのエラーメッセージが意味していることについての勘を磨くことになるでしょう。最終的には、コードを見ずに問題がどこにあるかさえわかるようになります（これは友人が同僚を驚かせて、イラつかせる面白い方法です😉） - どのように実装されているかを知らないままで、ある機能を壊す方法を考え始めるでしょう。これはテストケースの作成が上手くなるための第一歩になるでしょう。これはTDDを学び始めたらすぐ役に立つでしょう。 - わざと何かを壊してみたときは、それが壊れてしまったときに比べて気楽です。エラーに対処する方法は恐れではなく、好奇心を持つことです。「一体どうやったらこの問題を片付けられるんだよ！」ではなく「なぜこれは壊れてしまったんだ？」と考えましょう！ ### 参考 - [\.ymlファイルの「\*」や「<<」「<<: \*」とは何か？｜database\.ymlの&defaultや<<: \*defaultの意味を実例で解説](https://prograshi.com/framework/rails/meaning-of-codes-in-database-yml/) - [RubyでYAMLを拡張する方法と、外部ファイルのincludeに対応させる実例 \- Qiita](https://qiita.com/joker1007/items/7f1271a8bfcd774d8f46) --- ### 開催日 2023/2/20 ### 今回 Wrapping it up から ### 日本語訳 #### Wrapping it up 学んだことを試すいい遊び場を手に入れたら、その遊び場をコンセプトを自分のものにするために使おう。あなたが本当に手に入れたと感じるまでコンセプトの境界を探検しよう。その機能に関してあなたが質問を考えることからはじめよう。自然に出てくる質問もあれば、いろいろ考えなければならない質問もあるだろう。もし質問が思い浮かばなかったら、アイデアを出すために「この機能をどうやって壊すか」という質問を使ってみよう。いい質問を思いついたら、あなたの小さなRailsアプリを使って答えてみよう。あなたはそれらすべてに答えることはできないだろうが、試すことによってたくさん学びがあるだろう。 #### What do you when you're done with a tiny app? あなたが小さいRailsアプリで実験をし終えたときに、あなたはそれを削除してしまいたくなるでしょう。しかし私はしないことが多い。ストレージは安価だしRailsアプリはけっこう小さい。もしあなたがそれを使い終わったあとでもとっておいたら、あとで役に立つだろう。 - あなたが学んだことが実際に出てきたとき、あなたの小さいアプリがすでに使われているすばらしい例となる - もしRailsの機能に関する質問が出てきたら、面倒な作業を回避することができる。あなたの遊び場はすでにあるから - あなたの初期に作ったものをみて、ここからたくさんのことを学んだことを実感することは満足感が得られるよ私たちは自分たちが望むほどはやく前進しているといつも感じられるわけではない。しかし、あなたの初期のコードをみると、あなたがどのくらい成長してきたかを目の当たりにできる。あなたの昔のコードは幼稚に（発展途上）みえるだろう、それらをすぐに書き直したいと思うだろう（書き直すことを我慢するには多くの意志の力が必要になるだろう）。だから古いコードは残しておこう。 ### 参考 - tend not to do：～しない傾向にある。 - don't tend to do：～する傾向はない。 - [later onとlaterの違い](https://talking-english.net/later-on-later/) - resist doing: 〜することに抵抗する。 --- ### 開催日 2023/2/27 - 書記：shirotamaki ### 今回 Don’t lose your apps! から ### 日本語訳 #### Don’t lose your apps! あなたのアプリをなくすな！もしあなたがそれを必要でないときに取っておく必要はありません。実は私はとてもこれが苦手です。よい名前を考えるより、テスト8みたいな名前を付けた`rails new test8`とする方が簡単でしょう。しかし、私が行っているプロセスは以下の通りです。 - あなたの全てのテストアプリを`~/Source/testapps`フォルダに生成しよう。本開発をするために使っているどんなフォルダも使っても、実際の作業で邪魔になることはありません。 - あなたが動かしているアプリの特定の機能を表す２つか３つの特徴を考えてみてください。私が使ったことのある例としては`“validation_contexts, gemfile_groups, rc_files, and validation_mixins`などがあります。それらをRailsアプリの説明に使いましょう。 - もしあなたがひとつの単語しか思い浮かばないなら、大抵あなたがやろうとしていることはあまりにも大きいことを意味します。それらをいくつかのアプリに分解して、小さなアイデアをテストしましょう。 - その後、lsコマンドで`~/Source/testapps`中を見ると、あなたが調べたものがすべてリストで出てきます。それはあなたの独自のRailsのリファレンスガイドになります。 #### Wrapping it up そんなわけで、小さなRailsアプリで動かし終えたあと、それを削除しないでおきましょう。後で参照するためにそのアプリを残しておきましょう。あなたの小さいアプリで良い名前を選ぶことは、あなたがそれを必要とした時に見つけるための役に立つでしょう。`test1..test57`のうちのどれが多態性（ポリモーフィック関連）を教えるものなのかを見つけ出すのは大変です。2〜3単語の名前がベストです。読み取るには十分短いが、ひとつの小さいアイデアにフォーカスするには十分な長さです。 ### 参考 - clog up - 〈機械などが〉〔油・ちりなどで〕動きが悪くなる, 〈人が〉〔心配・不安などで〕〈心・気分を〉悩ます，重くする, 〈管などが〉〔ちりなどで〕詰まる - afterward - のちに、そのあとで --- ### 開催日 2023/3/6 - 書記：dawa ### 今回 “Putting it all together” から ### 日本語訳 #### Putting it all together もしあなたがRailsの新しいアイデアを学びたいと思ったらすぐにそれを使わなくてはだめです。もしあなたがこの章の次のステップに従ったら、あなたが望んでいたのRailsについての深い知識を築くことができるでしょう。 1. あなたが読んだものが何か面白そうだと思えたら、あるいはそれについて疑問を持ったらrails new 小さなRailsアプリを生成しましょう。あなたのすべてのテストappについて、サブフォルダを使いましょう。　そのアプリに対してあなたが学ぼうと思っている考えについての2単語から3単語の良い名前を付けましょう。 2. あなたが学ぼうとしていることの簡単な例を小さなアプリの中にビルドしましょう。 3. もしRailsアプリのUIをとおしてテストしなければならないときは、bin/rails serverコマンドでサーバを立ち上げて、http://localhost:3000 にアクセスして試しましょう。 4. もしブラウザなしで動かせるような小さいものだったら、bin/ rails consoleコマンドでコンソールを立ち上げて、ビルドしたものを実際に試せます。 5. もしコンソールでセッテイングするのがいらいらしたら、偽のテストを書いてbin/rails testで実行したり、一つだけテストケースを実行させてみよう。 6. もしあなたが繰り返し可能なセットアップとコンソールがほしいとき、　テストの中でpryを使いましょう。 7. あなたが探求しているアイデアについてのいくつかの質問のアイデアを出しましょう。 8. あなたが書いたコードを修正することによって小さなRailsアプリの中でそれらの質問の答えを発見してください。 ### 参考 - in-depth - 形：徹底的な, 綿密な, 詳細な --- ### 開催日 2023/3/20 - 書記：Hikaru ### 今回 “Chapter2 How to build your on Rails app” から ### 日本語訳 #### Chapter2 How to build your own Rails app どのように自分自身のアプリを作るか。あなたはまず、肩や足に変な、うずくような感覚によってそれを知ります。あなたはスクリーンに映る空のコマンドラインや骨組みだけのRailsアプリにストレスを感じて、どこから手をつければ良いかわからないでしょう。こんなときはHacker Newsを開いて、いくつかの記事を読む方がずっと簡単です。インスピレーションはいつか降ってくるはず、ですよね？この感覚は普通である。私が新しいRailsアプリを作ろうとするときはいつでも、いまだに私はコンピューターを永遠にあきらめて森の中や他のものに逃げたくなる。しかし私にはあなたがそんな状況を乗り越えるためにシェアできるプロセスを持っているので、あなたはアイデアを本当の実際に動くアプリに変えることができます。コーダーズブロック（開発者の抵抗？）空のRailsアプリはギョッとさせます。これはライターズブロックのエンジニアバージョンです。あなたはその恐れがどこから来るのかわかるかもしれません。redditを開いたときに感じるのと同じ感覚で、その日リリースされた10個の新しいgemを見て次のバージョンが出てあなたが学んだことすべてが無駄になる前に、どうやってそれらのgemを全部学ぼうか心配するような感覚です。あなたは目の前のタスクに圧倒されているだけです。そしてそれは素晴らしいです。なぜならその圧倒感と戦うのに使えるいくつかのシンプルなテクニックがあるからです。新しいRailsアプリというのはとても大きく、定義が不十分なタスクです。あなたにはアプリがこうあって欲しいという夢が頭に浮かんでいて、それが始めることを不可能にしています。考えなければいけないことが多すぎますし、作るべきものも多すぎます。このように、大きくて曖昧で圧倒させるようなタスクに直面した時、答えはいつも同じです：分割しましょう！あなたの大きなアイデアを、あなたが行きたい場所に繋がるような小さな複数のタスクに分けましょう。あなたはアプリの完成に近づくための道筋を得るでしょう。 ### ChatGPTに要約してもらった文章自分のRailsアプリを作成する方法新しいRailsアプリを作成しようとすると、どこから始めたらいいかわからずストレスがたまることがよくあります。この感覚は普通のことです。大切なのは、この感覚を乗り越えてアイデアを実際のアプリに変える方法を見つけることです。プログラマーにとって、空のRailsアプリは怖いもので、それは私たちの「開発者ブロック」です。この恐怖感に対処するためには、大きな課題を細かいタスクに分解していくことが鍵です。小さなタスクをこなしていくことで、アプリの完成に近づいていくでしょう。 ### 参考 - [ライターズ・ブロック \- Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%A9%E3%82%A4%E3%82%BF%E3%83%BC%E3%82%BA%E3%83%BB%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF#:~:text=%E3%83%A9%E3%82%A4%E3%82%BF%E3%83%BC%E3%82%BA%E3%83%BB%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF%20\(%E8%8B%B1%E8%AA%9E%3A,%E7%94%B1%E6%9D%A5%E3%81%99%E3%82%8B%E3%82%82%E3%81%AE%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%84%E3%80%82) - [Reddit \- Wikipedia](https://ja.wikipedia.org/wiki/Reddit) - アメリカ合衆国の掲示板型ソーシャルニュースサイト --- ### 開催日 2023/3/27 - 書記：uda ### 日本語訳 ### What to build first あなたのアプリケーションを始めることはストレスの最初の波を乗り越えることを助けるだろう。現状、しかしあなたは始めるためのものは何もない。あなたは頭で考えているときには組み立てるのが簡単そうにみえる、大きくて曖昧なアイデアを持っているだけだ。しかし今まさに、現実のものにしようとすると、不可能に感じるだろう。例えば、あなたは取り組んでいるプロジェクトでバグを追跡するアプリを作ることを決めたとする。（GitHub issuesのような）それはマイルストーンやワークフローやタグを持っているから、良いバグトラッカーになるにちがいない。しかしそれらすべての機能を、どこから始めたら良いだろう？あなたはすべてのことに取り組むことはできない。だからひとつのことをやらなければいけない。 ### How do you choose the first thing to work on? あたなが新しいプロジェクトを始めるとき、最初にどれをやるかを決めるのを助けるこの短い手順を試してください。何分かとってあなたが作ろうとしているものについて考えてください。頭に浮かんだすべての機能を書き出してください。ユーザーがアプリケーションを通してたどることができるだろう様々な道筋を考えてください。いろんな道筋でできるいろんなことを考えてください。それぞれについて1行で説明してください。そうしたら、もしそれがなければアプリが存在できないようなパスにフォーカスしてください。コアパス。コアパスとはもし誰かがあなたのアプリを30秒で説明するよう頼んだらあなたが話すであろう事柄です。もしあなたがフォーラムソフトウェアに取り組んでいるとしたら、トピックに投稿したり返信することがそのプロジェクトのコアになるでしょう。もしあなたがiPhoneに通知を送る方法に取り組んでいるなら、デバイスを登録したり通知を送ることがコアパスになるだろう。初めの頃にあまり多くの作業なしでアプリで遊べるので、コアパスから始めるのは良い。あなたは新しい機能を作るためのしっかりした土台を得るだろう。そしてそれらによって次の機能をより簡単にスタートさせることができるだろう。もしあなたがどのコアパスに最初にフォーカスするか決められない場合は、どれを選んでも本当は重要ではない。1つを選んで（必要だったらランダムに）、あなたがそれにどうやって取り組むかをみてみましょう。 ### 参考 - [What is the meaning of "build off of"?](https://english.stackexchange.com/questions/102057/what-is-the-meaning-of-build-off-of#:~:text=Build%20off%20of%20means%20just,%22%20or%20%22elaborate%20on%22.) --- ### 開催日 2023/4/6 - 書記：tamaki ### 日本語訳 ### "A quick example" 簡単な例ブレイクダウンしよう（もっと分解してみよう）バグトラッカーを作るには、次のようなことが必要になる。 - ユーザーにバグを割り当てる - マイルストーンにバグを割り当てる - バグを作る - バグをアップデートする - タグの付いたバグをすべて表示する - そして、それ以上の機能も… 考えられる機能はたくさんある。バグのレコードを作ることなしには、バグトラッカーを持つ意味がないバグ記録の作成？それは、システムの他の多くを構築することなく構築できるもののように思える。それは独立している。依存しない。単独で動作する機能は、スタート地点としてうってつけの場所。よりシンプルになる。では、バグレコードを作るところから始めてみよう。でも、アプリの開発の進捗がでているのであれば、異なる決定をするのも大したことではない。バグレコードを作成できるアプリを書くことは、GitHub Issuesのフルのクローンを作ることより簡単にできる。あなたはすでに開発を始める場所を知っているかもしれない。ですが、仮に知らないとしても詳細に進んでいこう。いくつかの機能は、他のものに比べて考えることが難しいかもしれない。それらはより計画を必要としている。 ### “Which part of the feature should you start with?” 機能のどの部分から始めるべきか？あなたはコアパスを作る準備ができると、あなたの頭の中にある全てのオブジェクトのモデルを書きたくなるだろう。恐らくあなたは、マイグレーションを作成し、属性を加え、それら全てを関連付けたくなるかもしれない。しかし、すぐにたくさんのパーツがあり、すべてがうまくフィットしないかもしれない。あなたがアプリを実際に使えるようになるまでには、すごく時間がかかるだろう。また、モデルをうまく設計できなかった場合、UIを構築して実際にアプリを使い始めるときに、その作業をもう一度やり直さなければならない。逆のアプローチを取る方がずっと簡単です。誰も見ることのないものをなぜ作るのですか？将来の機能のためにデータモデルが必要になるかもしれない場合、なぜその機能を構築する前にそれを作成するのですか？（機能がないのにモデルを先に作るな。という事） --- ### 開催日 2023/5/1 - 書記： Hikaru ### 日本語訳 ### “Which part of the feature should you start with?” あなたがソフトウェアを書く時、一貫性のために、またはのちに必要になると思っているという理由でコードを書きたくなる。しかし、あなたが書くすべての行にバグが忍び込んでしまう可能性がある。自分のコードで未来を予測し、実際にそれが当たったときは、本当に感激する。しかし、まだ利益を産まないコードの全てがそこに存在してしまいます。これらはバグを引き寄せる磁石のようなものです。なぜならそのコードは使われていないからです。あなたはコードベースの一部を実行するときはいつでもそれらについて見て考えなくてはならない。一般的に、少ないコードは良いコードだ。そしてViewから始めてModelに向かって作っていくのが、私の知る中で、一貫して少ないコードを書くためのベストな方法だ。なのでUIから始めましょう。そしてUIで見えるものからデータモデルを推測しましょう。 OmniGraffleやBalsamiqのような、ラフな機能スケッチを作るためのツールはたくさんある。私はたくさんのツールを試したが、いつもペンと紙に戻ってしまう。人々がどのようにあなたの機能を使うかを考え始めるためには、四角・矢印・テキストで通常は十分だ。そしてそれこそが現時点で探しているものだ。デザイナーになる必要はない。 ### 開催日 2023/5/8 - 書記： uda ### 日本語訳 If you have to share~ もしあなたはスケッチをシェアしなければいけない場合、紙とペンはそれほど便利ではないかもしれない。しかしそれでもあなたは紙で書くことからはじめたほうがいいかもしれない。そしてあなたはちゃんとしたスケッチができたら、それを共有しやすいツールに移すのも簡単である。私が機能をスケッチするときは以下の手順に沿ってやります。 1. 早い段階で小さくてコアな機能をとりあげます 2. 誰かがその機能を使ってできるひとつのシンプルなことに絞って考えます 3. シンプルなことができる人のためだけのスクリーンを作ります 4. あなたが誰かにしようとしていることを教えるかのようにアクションの道すじをえがきます（操作方法） 5. その道すじを説明するとともに、オブジェクトを書き出して、そのオブジェクトのプロパティを書き出して道すじを開発するのに必要だと思うその他のアクションについても書き出しますだから例えば、バグトラッカーに適用するとこちらです。（上と同じ文章は省略）↓ 1. バグの記録を作る 2. バグレコードを作るための必要最低限のものは何ですか？それをタイトルと説明だとしましょう。おそらく誰かにバグをアサインすることができるようにした方が良いでしょう。しかし割り当てられた人なしに便利なバグトラッカーを持つことができますか？じゃあ、それを私が使うものだとしよう。アサインされた人なしでやりましょう。ここにアクションがあります ### 開催日 2023/5/22 - 書記： shirotamaki ### 日本語訳 “A user can create〜" 2. バグレコードを作るための必要最低限のものは何ですか？それをタイトルと説明だとしましょう。おそらく誰かにバグをアサインすることができるようにした方が良いでしょう。しかし割り当てられた人なしに便利なバグトラッカーを持つことができますか？仮に、自分がそれを使うなら。アサインされた人なしでやりましょう。ここにアクションがあります。ユーザーは、タイトルと説明を付けてバグのレコードを作成することができます。今は技術的にスキップできる関係があるアクションが無料でゲットできます。ユーザーは過去に作ったバグのレコードを見ることができる。結局のところ、こんな感じでさらなる努力をすることなくわかる追加の機能を見ることができる。そんなことがなくても、全然OKです。時間をかけて何回もやればわかるようになるでしょう。 3. シンプルなことができる人のためのスクリーンを描きます。私はアーティスではないということが、間違いなく証明されます。でも、そうである必要はないんだ！この時点では、ビジュアルではなく対話的に考えているのです。曲がりくねった線と矢印が対話の方法です。30フィート離れたところから、あなたのアプリがどのように見えるのか？考えましょう。 ![](https://hackmd.io/_uploads/SJxO_HA_B2.png) 4. そのアクションの道筋を誰かに説明したような感じで説明してください「誰かがフォームにやってきた。彼らはタイトルと説明を書くことができ、決定ボタンを押す。さっき入力したバグのレコードを見ることができるページに遷移する。」 5. その道筋を説明するとともに、オブジェクトを書き出して、そのオブジェクトのプロパティを書き出して、その道筋で必要だと思われる他のアクションを書き出してください。OK、これらのスケッチが何であるのか？私が説明したことが何だったのか？考えてみましょう。私はタイトルと説明が付いたバグレコードを見ました。それだけです。とてもシンプルです。明らかに、これは基本的な機能ですし、Railsはまさにそれを作るように設計されているものです。しかしRailsがこのような機能を作るために設計されている理由は、多くのWeb開発がこのような機能を作っているからです。そしてあなたのスケッチを見て、高度過ぎるもしくは作るのに一日以上かかると思ったら、より小さく考えよう。そのアクションに取り掛かるために、2,3個のステップに分割することができますか？あなたは、そのアクションをシンプルにするために少しの機能を削ることはできますか？あなたはscaffoldで始めて、一度基本的な動くものを作ったら、より複雑なパーツを作ることはできますか？ --- ### 開催日 2023/6/12 - 書記： dawa ### 日本語訳 “Wrapping it up〜." It’s hard to start Rails apps.〜 Railsのアプリを立ち上げるのは大変です。それはなぜかというと、実際にアプリを作り始めるまでは、頭の中にあるアイデアは巨大で曖昧で複雑だからです。なのであなたのアプリを小さな機能に分割しましょう。そうしたら一つのシンプルな核となる道筋から始めましょう。一番最初の機能を作り始めてしまえば次の機能さらにその次の機能に対するはずみを付けられるでしょう。取り掛かるときは一つの小さな機能のUIから始めましょう。これは1から5 1. 早い段階で小さくてコアな機能をとりあげます 2. 誰かがその機能を使ってできるひとつのシンプルなことに絞って考えます 3. シンプルなことができる人のためだけのスクリーンを作ります 4. あなたが誰かにしようとしていることを教えるかのようにアクションの道すじをえがきます（操作方法） 5. その道すじを説明するとともに、オブジェクトを書き出して、そのオブジェクトのプロパティを書き出して道すじを開発するのに必要だと思うその他のアクションについても書き出します一度あなたが最初の小さな機能を作るとあなたは実際にあなたのアプリをつかうことができるようになるでしょう。そしてそれはそのとき本当に楽しくなってくるよ。 "Exercises" This process doesn’t come naturally.〜このプロセスは自然やってこないでしょう。これは練習が必要なんです。幸運なことにどこでも練習することができる。その機能は機能をブレストする。そしてそれらはこれらのアプリのアイデアに向けた機能、いくつかの考えられる機能を考えることにトライしましょう。5から10の小さないくつかの機能についてトライしましょう。 - ユーチューブプレイリストのダウンローダー - ToDoリスト - メッセージボード - スケジュール調整アプリ - Q&Aフォーラムそうしたら私が説明した基準を使って一番最初に始めるための機能を選びましょう。もし誰かがあなたにそのアプリについて聞いてきたら30秒で説明するために話す機能。もし選ぶのに困ったらいくつかの上にある選択肢の中からランダムに一つ選びましょう。選ばないよりはマシです。あなたが選んだそれぞれの機能のために次の５つのプロセスに従ってください。実際のスケッチを書くことと、あなたが始めるに当たって必要なオブジェクトを計画することまでやってください。最初は大変そうに見えても心配しないでください。とりあえず決めて続けてみましょう。(あなたにとってまあまあ良くて、オンライン上の評論家ではないですよ) 次に別の機能を選んでもう一度このプロセスをこなしたら、あなたがより心地よいと感じ始めるまで続けてください。もしあなたがこの本で何かを練習するとしたらそうなるに違いない。あなたがいつでも新しいRailsアプリをスタートすることができると感じれば、残りのプロセスはあなたにとって簡単になるでしょう。 ### 開催日 2023/6/26 - 書記： Hikaru ### 日本語訳 #### "Turning your ideas into running Rails apps" Now that you have a rough idea〜 "あなたのアイデアを動いているRailsアプリに変える" 今、あなたがビルドしているものについてのラフな考えがあるのなら、それを実際のコードにしてみましょう。そしてもう一度UIから始めて、そこからモデルに落とし込みましょう。あなたがコードを書き始める前にどのコードを書くべきか知る必要があります。あなたはこれを今ちょうど書いたスケッチから見出すことができます。あなたが描いたスクリーンはあなたのアプリのビューに対応していて、あなたが選んだアクションはコントローラーアクションに対応しています。だからあなたが以下のことを理解するのにスケッチが助けられることがいくつかあります。 - どのビューを書く必要があるか？ - どのコントローラーとどのコントローラーアクションを私は必要としているか？ - どのデータをそれぞれのコントローラーが管理する必要があるのか？これはRailsの経験があまり無いと大変かもしれません。なので私のスケッチを使って一例を一通りやってみましょう。再掲します：（画像）このパスには3つのメインとなるスクリーンといくつかのフォーム要素と一つの表があります。ここから始めてみて、これらの質問に答えられるでしょうか？