6.22日報

10:00~12:00

db設計

昨日のTMGでツリー構造のカテゴリー分けをシンプルにできるgem見つけた

という話の流れからその周辺のdb設計を担当する事に

ancestryというgemで

f:id:uskyade:20200622110828p:plain

と行った具合で親id/子id/孫idといった感じで表記される。

これ考えた人エライ

 

f:id:uskyade:20200622111147p:plain

最初はこういう考えでした

これだと今後、孫やひ孫が現れた際、カラムを増やして上げないといけなくなる。

きっとめっちゃ大変。

 

あとは

f:id:uskyade:20200622111406p:plain

こういう三角関係。

これだと親カテゴリーに対して子カテゴリーが全然関係ない親の子供ですって言えてしまいそうなのが気になっていた。

 

ancestryはそれらを解決してくれそうな気がする。

(まだ使ってないから)

あと1/2/8といった具合で分数表記されるが文字列になるらしい

(type=integerて下書きしてた)

 

12:00~12:30

デイリードリル34

暗号化されたシーザー言語を元に戻すという問題

シーザー言語を作るコードを書いた

記事を見つけたので単純に逆転させました。

char = "frqjudwxodwlrq"

puts "暗号化前: #{char}"

code = []


char.chars.each do |char|
num = (char.ord - 3)
code << num.chr
end

puts "暗号化後: #{code.join("")}"

 

デイリードリル35

クラスの定義について

class User
  # ブロックの内部で各種メソッドを定義
end

 

を使わないでクラスの定義するには?

何パターンかあるようです。

 

そのうちのひとつ

Tweet = Class.new do
  # ブロックの内部で各種メソッドを定義
end

と答えました。

 

このやり方だとブロック外の変数も呼び出せるようになるらしいです。

 

デイリードリル36

Railsで自動的に消費税8%を計算してデータにいれるというシステム

class Product < ApplicationRecord
  def add_tax
    self.price = (price * 1.08).round
  end
end

としてから

コントローラーにも

少し追記

 

こうすれば、ユーザーが入力した価格に自動で消費税額8%を加算してからデータベースに保存することができるとの事です。

 

12:30~14:30

朝、下書きしたやつの清書

チームで作り始めたやつに初書き込み緊張する。

バグりませんようにと願いながら作業始めました。

下書きしてるので入力はすぐ終わりましたが

他メンバーに迷惑かけるわけには行かないので

pushのやり方は慎重になる。

 

しっかり確認したあと1回目は

招待メールからの参加申請を忘れていてあなたには書き込み権限が無いと言われる

リーダーがrails new したやつでテストしてたからそれでできる気になってたが

デプロイ担当さん作り直した方でチームは進んでたのでうっかりでした。

 

16:00~17:30

デイリードリル37

[A].haml
1
2
3
@users = User.all
@users.each do |user|
  = render 'user',  user: user
[B].haml
1
2
@users = User.all
  = render 'user', users: @users

 

上記コードでどちらの方がいいか?という問題

Bの方が短いからいいんじゃないかな?と直感で選択

短いコードの方が処理にかかる時間も短いと聞いた事あるような気がしたが

each文を使ってるのが余計なようだ。

[A]では、@usersにeachを使用して、user一人一人に対してrenderを実行しています。
この書き方だと、userが100人いると100回、50000人いると50000回、どの部分テンプレートを利用するのか探しにいく処理が実行されるため、ユーザーが多ければ多くなるほどパフォーマンスが低下していきます

 

 

デイリードリル38

ルーティング問題

resourcesとresourceの違いについて

resoucesしか使ってなかったからそもそも知らんかったけど

まずそういうのもあるんやと思いました。

調べると大きく分けて二つ違いがあるようだ

 

まず

resourceの場合は、indexの定義がされない

indexなかったらどこにいくんやろ?て感じですがそれは実際使った時に検証しようと思う。

 

次に

resourceの場合はプロフィールは必ずログイン中のユーザーに紐付くので、「:id」による絞り込みも必要なくなります

という事でidも省略?されるそうです。

 

デイリードリル39

アプリケーションのコントローラに関する問題

https://qiita.com/okamoto_ryo/items/52e3506e06c27631395e

この記事を参考に解答しました。(ほぼ丸写し)

 

デイリードリル40

https://qiita.com/okamoto_ryo/items/2b835aae37d0dd319246

この記事を参考に覚ました。(ほぼ丸写しリターン)

この人きっとテックキャンプ 卒業生やな。

なんかよく見かける気がする。

 

デイリードリル41

管理者ページ作成について

これは管理者がいるアプリ作ろうとしてたから少しわかった

admin,namespaceのやつやな。

 

デイリードリル42

rakeタスクを、ターミナルから実行するためには

rake [namespeceの名前]:[taskの名前]のように記述して実行します

との事です。

 

デイリードリル43

https://qiita.com/okamoto_ryo/items/200dc48b1da2a0dfc161

この記事を参考にしました。

 

デイリードリル44

解答見てもピンとこんかった

belongs_toはメソッドであり、:userが第一引数、dependent: :destroyが第二引数となっている。

第二引数の記述はハッシュの{}を省略した形で、{dependent: :destroy }を意味している

 

送られてきたリクエストによって、レスポンスを振り分けている。
たとえば、/tweets.jsonというURLでページを開いた場合、json形式で変数@tweetsの中身が展開されます。

 

17:30~18:30

ずっと詰みっぱなしだった個人アプリが進んだ

ただの入力ミスというか

コピペからのこのアプリに合わせた名前に変換できてなかっただけやった。

 

19:30~21:00

チーム開発においてこれから起こりえるトラブルについて考えてみた。

夜間休日コースという事もありみなさん使える時間も時間帯もバラバラ

まだ始まったばかりのためタスクもたくさんあるため何から手を付けたらいいか

検討もつかない

 

21:00~21:30

TMG

今日の成果報告と

明日やる事決めました。

それと今後、ルール化した方が良さそうな点もあったので報告

これは明日のTMGで決める事になるかな?

 

今日の学習時間9h

今週の学習時間9h

6月の学習時間180.5h