学習[52]日目
本日の学習内容
BEMって何？
Hamlって何？
クラスとインスタンスの復習
BEMって何？
Block、Element、Modiferの3つの頭文字をとったものでBEMを使用して命名することで、クラス名だけでHTML要素の意味を伝えることができます。
Block ：ある要素の大元となるブロック要素で、命名には名詞を使用
1つ以上のElementによって、Blockが構成されている
Element：Blockに属する子要素で、命名には名詞を使用
Modifier：Blockまたは、Elementに特別な修飾をする要素で命名には形容詞を使用
また、BEMの命名規則は以下の2つになります。
- BlockとElementをつなぐ場合は、__(アンダースコア2つ)でつなぐ
- Modifierにつなぐ場合は、--(ハイフン2つ)でつなぐ
Hamlって何？
「HTML Abstraction Markup Language」の略称で、htmlよりもコードを早く、シンプルに作ることができます。
また、Rails使用しているerbと同じでrubyのコードを埋め込むことが出来るのですが、erbと比べて閉じタグやend不要であることやインデントで階層構造を表すことが特徴です。
実際に比較すると以下のような違いがあります。
#htmlによる記法
<!DOCTYPE html>
<html>
<body>
<div class='container'>
<header>
<h1>title</h1>
<h2>subtitle</h2>
</header>
<div class='contents'>
<div class='box'>
<h2 class='box-title'></h2>
<p class='box-discription'></p>
</div>
</div>
<footer>
</footer>
</div>
</body>
</html>
上記は見慣れたhtmlの形式です。
#hamlによる記法
!!! 5
%html
%body
%div.container
%header
%h1 title
%h2 subtitle
%div.contents
%div.box
%h2.box-title
%p.box-discription
%footer
一方、hamlでは非常に簡略化されていることがわかります。
しかし、注意しなければいけいない点もあります。
階層構造をインデントによって表しているため、htmlのように適当にインデントを入れてしまうとエラーが起きてしまうのでその点は気をつける必要があります。
クラスとインスタンスの復習
久しぶりに復習をしましたが、結構忘れてました。。
class Book
def initialize(author, title)
@author = author
@title = title
end
def author
@author
end
def title
@title
end
end
book = Book.new("本の作者", "本の名前")
puts "著者: #{book.author}"
puts "タイトル: #{book.title}"
上記のような感じで簡単なクラスとインスタンスを見てみた時にnewメソッドでインスタンスを生成した際にinitializeメソッドでインスタンス生成時に引数として定義した変数に任意の値を入力させることやインスタンスメソッドを定義してインスタンス変数を返り値とさせることなど単純ですが、忘れかけていたものを復習出来て良かったです。
以上で本日の学習内容は終わりになります。
最後までお読み頂きありがとうございます。
学習[51]日目
本日の学習内容
Sassって何？
Sassって何？
CSSの機能を拡張した言語で、CSSに非常に似ていますが異なる言語です。
Sassには以下のようなメリットがあります。
●記述の簡略化が可能
CSSでは、親の要素から対象要素までのセレクタを何度も書く必要がありますが、Sassは親子関係にあるセレクタをネストして書くことができます。
ネストして記述することで深い階層になっても親子関係がわかりやすく、親要素を複数記述しなくて済むといったメリットがあります。
●処理が簡略化可能
Sassでは変数や条件分岐といったプログラムのような処理を記述でき、CSSよりも柔軟なコーディングが可能となります。
例えば下記のように色の指定をする際など何度も使用する値は変数を定義することで、変数名で何度も利用することが可能です。
＃$変数名: 値;で定義可能
$menu-color: rgb(10, 10, 10); list { background-color: $list-color; }
上記のような変数定義による記述の他にもmixinという機能を使用することで、同じスタイルをまとめることもできます。
変数が値を定義するものに対して、mixinはスタイルを定義するもので、同じスタイルを記述する必要がなくなります。
mixinを定義するには、@mixin mixin名() {}のように記述します。
実際の使用例に関しては現時点でイメージがつかないので後で理解した上で追記したいと思います。
●複数のCSSファイルを1つにまとめ管理可能
Sassではパーシャルという機能を使用することで、複数のSassファイルを1つのCSSファイルとしてまとめることができます。
パーシャルとは、分割したSassファイルのことで、ファイルを分割することで、機能や内容ごとに管理が可能になります。
パーシャルを利用することで通常のcssのように一つのファイル に全てのスタイルを記述すると文量が膨大になり、可読性が悪くなることを防ぐことができます。
＃パーシャルファイルを作成
ファイル名を_（アンダースコア）から開始
@import ファイル名と記述することで読み込みが可能
@import "reset";
個人的にrailsにあったrenderメソッドに似てるように感じました。
Sassを利用するにあたり通常のCSSファイルには記述することができませんが、SassファイルにCSSを記述することは可能となっています。
Sassを扱うファイルの拡張子は.以下の2種類があります。
.sass
最初に作られたSassの記法（SASS記法）を扱うことが出来ます。
SASS記法では波カッコの省略やセミコロンが不要などのモダンで非常にシンプルな記法という特徴がありますが、現在主に利用されているのは後述する.scssの方になります。
.scss
CSSに非常に似た記法（SCSS記法）でSassの機能を使うことが出来ます。
Sassを実際に使用する場合に関して以下のようなフォルダ構成が一般的なようです。
●index.html
●style.css
●stylesheetsフォルダ(すべてのscssファイルを管理するフォルダ)
●style.scss
●_reset.scss
●configフォルダ(プロジェクトの設定ファイルや、scssで使用する変数を定義するファイルなどを管理するフォルダ)
●mixinフォルダ(scss内で使用するmixinファイルを管理するフォルダ)
●modulesフォルダ(モジュールを管理するためのフォルダ)
●vendorフォルダ(ライブラリのファイルを管理するフォルダ)
●overrideフォルダ(vendorフォルダに格納してある外部のライブラリを上書きするためのscssファイルを管理するフォルダ)
以上で本日の学習を終了致します。
最後までお読み頂きありがとうございました。
学習[50]日目
本日の学習内容
Ruby復習
-
if文を1行で書く
-
else ifを使用しない場合の条件分岐
データベース設計
if文を1行で書く
#通常
str = "豚カツ"
if str.include?("豚")
puts str
end
＃１行で書く場合
str = "豚カツ"
puts str if str.include?("豚")
1行で書く書き方に関してはシンプルな記述であればこの方が見やすいかなと感じました。今までendとセットで書く気方しか行っていなかったので使用していこうと思います。
else ifを使用しない場合の条件分岐
#else if使用する
num = 1
while num <= 12 do
if num % 6 == 0
puts "豚カツ"
elsif num % 2 == 0
puts "豚"
elsif num % 3 == 0
puts "カツ"
else
puts num
end
num += 1
end
＃else ifを使用しない
num = 1
while num < 13
str = ""
if num % 2 == 0
str = str + "豚"
end
if num % 3 == 0
str = str + "カツ"
end
if str == ""
str = str + num.to_s
end
puts str
num += 1
end
こちらに関しては、どっちの記法が正というかいい書き方なのか分からないので調べたいと思います。
データベース設計
データベース設計に関しては、手直しを実施しました。
主キーをカラムとして追加して記載をしていましたが、テーブル作成時にはテーブルにidが設けられるためわざわざカラムを設けることで重複データを作ってしまうことになるので気を付ける必要がある。
また、中間テーブル設計後にアソシエーションの記法を誤っていたのでそちらに関しても訂正と復習を実施しました。
以上の本日の学習でした。
最後までお読み頂きありがとうございました。
学習[47,48,49]日目
本日の学習内容
データベースを設計してgit hubで管理する前に。。。
生活の反省
夜勤での生活の乱れからアウトプットが出来ずに終わってしまう日が続いてしまいました。。
学習のために生活リズムを変化させようと帰ったら今までは夕方になったら寝るという戦法から帰ってきたらすぐに寝て起きてスッキリしたら学習しようという作戦だったのですが、永遠と爆睡した挙句、睡眠の質も低下するというドツボにはまりました。
本来は机とかで数分仮眠するというのがいいそうで、私は布団でがっつり寝るということをしていました。。(副交感神経の関係らしい)
次の夜勤時は反省してこれを取り入れます。
ということで反省はおいといて表題の通り進めていきます。
データベースを設計してgit hubで管理
まず、ターミナル上でアプリを作成(rails new "xxxxxx")
↓
データベースの作成(bundle exec rake db:create)
↓
また、rails gコマンドでコントローラを作成した際に作成したファイルに対応したstylesheet・Javascript・helper・test_frameworkが同時に作成されないようにconfig/application.rbにて設定を変更します。
↓
次いでgitでアプリを管理するようにするためgit initでローカルリポジトリを作成
↓
git hubにコミット(commit)、プッシュ(push)してリモートリポジトリの作成
↓
マスターブランチから作業の為のブランチの作成
↓
プルリクエスト
[空のコミットを作成する]
[プッシュする]
[プルリクエストを作成する]
[同じブランチで変更修正を加えていく]
↓
作成した作業用のブランチに変更して、作成したアプリのDB設計書の作成
↓
改変したコードをコミットしてプッシュ
のような形でアプリをgit hub上で管理できるようにして、データベースの設計を行いました。
データベース設計に関して学んだこと
データベース設計にあたり
●必要な要素を全て書き出す(user,E-mail,groupとか)
●要素同士の関連性を考える(userのE-mailやuserの所属するグループのように)
●要素を箱として大きい箱に小さい箱を入れていく(userの中にE-mailやmessageが入る、messageの中にはtextやimageが入る)
●箱で中身があるものはテーブルにして中身のない箱はテーブルのカラムにする(userやmessageは中身があるのでテーブルにして、E-mailnには中身がないのでuserのカラムにしてしまう)
●テーブルの正規化を行う
●テーブル同士のリレーションやカーディナリティを決める
●カラムの制約等を決める
みたいな形で実装してみたら形になりやすかった気がする。(個人的な感想)
従属性と非従属性に関して一概に決められているものではなく、使用者側のルールに依存するものであることが分かりました。
例えば、あるものをを作るのに設計→作成という流れがあったとします。
Aという所では作成という工程は設計という工程がなければ発生しないので作成は設計に依存しているという関係ができます。その為、作成テーブルには主キーとして設計idが設定されるということになるかと思います。
一方、Bという所では、作成という工程が設計工程が無くても急ぎの場合には工程を無視して作成はできるとなっていた場合には、設計と作成は依存関係にはないことになります。その為、作成テーブルには設計idが主キーとして設定されなくなってしまいます。
このように考え方によって依存性の関係が変わってしまうところが設計する上で難しいところなのかなと感じました。
学習に関して学んだこと
冒頭で生活に関しての反省点を挙げましたが、学習に関しても言えることで、その時の体調によって学習方法も変化させないと効率が上がらないなと感じました。
例えば、短い時間でしか学習できない場合には、
まずやろうと思っている箇所の概要を一旦確認する(数分とか時間は決めて)
↓
どのように区切りをつけて学習するかタスクを作成する
↓
タスクごとに目安時間を決めて学習
というような感じでタスクを作成して短いスパンで学習するような方法を取り入れれば、短時間の学習時には有効なのではということで実践していきたいと思います。
プルリクエストの際の注意点
プルリクエストに関しては以前に学習しましたが、実際に人に向けて書いたことがなかったので注意点をまとめておく必要があるなと感じたのでまとめます。
- 実装途中で作業中のもののタイトルに関してはWIPのような目印が必要
- 詳細はWhatとWhyに基づいて記載を行う
- マークダウン表記で書く(反映されているかはpreviewで確認可能)
上記のようにプルリクエストは人に見せるものであるということを意識して記入するようにしないといけないということが分かりました。
特に他人が実装中のものを触ってしまう恐れがあるタイトルに関しては要注意だなと感じました。
小ネタ
コードを書くものとしてVscodeを利用しているのですが、今までターミナルを別で起動して使用していたのですが、command+`で統合ターミナルというものを利用できることを知りました。
以上で本日の学習は終わりです。
明日からは生活のリズムが元に戻るので頑張って学習を続けていきたいと思います。
学習[46]日目
本日の学習内容
データベース設計
作成作業に関していざやってみようとしたのですが、実際にやってみると思った以上に書けずどこから手をつけようかという事でまた最初に戻り段階を持つ少し細かく見て、理解していこうと思いました。
まず、DBによってデータを管理する為に現実の世界を抽象化してデータモデル(以下、DM)を作る事が必要です。DM作成作業は，概念設計，
概念設計
DBによって管理の対象とするものを現実の世界から抽出して概念モデルを作成します。概念モデルの作成は、エンティティとリレーションによって行われます。
論理設計
概念設計によって作成された概念モデルを，
そこで，
また，テーブルの列としてデータ型を決定し，
物理設計
この段階でDBとしての性能について考慮します。
物理設計によって修正された物理モデルが実際にデータベースによって管理することができる形式となります。
感想
こんな感じで設計のも段階が分かれていることを知る事が出来ました。
また、用語に関してある程度分かっていると今までわからなかった内容に関してもより学習する事が出来流ので情報の深堀もできている気がしました。
本日は少しアウトプットとして身近なものを使用してデーターベースの設計をしてみましたが、概念モデルの部分でエンティティに関しての洗い出しが少し実践を重ねないといけないなと感じました。
特にエンティティの中でもリソース系とイベント系と呼ばれる2種類あるのですが、イベント系の概念に関してリソース系のものから発生する動作等を考える出して洗い出す必要性があるので単純発想のみだと抜け漏れしそうだと感じました。
学習[45]日目
本日の学習内容
データベース設計について
データベースの正規化
データベースの正規化はデータベースのデータ構造をより効率的で重複や無駄のないシンプルな構造にするために行うことなのです。
しかし、正規化をすればするほどいいというわけではなく一般的に３段階目程度で留めておくのが良いそうです。(正規化には段階があります)
その理由としては正規化を繰り返すほどテーブルが細かくなり、細かくなれば当然テーブル間のデータをまとめたりする処理が増えるのでSQLによる処理工程が多くなり、データの処理に必要以上の時間が掛かるみたいので注意しなければいけない点になります。
中間テーブルとは？
私自身がここまでの学習においてアソシエーションというものを学んできましたが、
1対1や1対多などで多対多に関してはまだ学習していませんでした。
この多対多の関係において必要となるのが中間テーブルです。
例えば、昨今のSNSにはタグ付けというものが存在しますが、タグはエンティティとして扱われており、投稿内容に対して多数のタグを付与することが出来る一方で同じタグでもいろんな人の投稿内容に付与されることからこれらのリレーションが多対多になるといことが言えます。
この時、中間テーブルを設けない場合に何が起こるかというと投稿内容のテーブルではタグを複数持つという状態が生じてしまいます。一方でタグにおいても複数の投稿内容を持つという状況が生じます。これにより一つのカラムに複数のデータが入ってしまっているので特定のデータの呼び出しが出来なくなります。
これだとダメだからといってこれをそのままバラそうとするとカラムが横に無駄に広がりマルチカラムアトリビュートというものを引き起こします。
そこで投稿内容のidとタグのidをカラムに含めた中間テーブルを設けることでタグと陶子内容のリレーションをうまくしてあげる事が出来ます。
結局、ER図に関しては少ししか出来ず設計をうまくやる為に利用できなかったので、際復習して明日まとめるようにします。
今日は今から寝て夜勤に備えねば！
最後までお読みいただき有難うございます。
学習[44]日目
本日の学習内容
データベース設計に関しての基本フローと用語の理解
データベース設計は主に下記の手順で進められます。
データベースで管理するエンティティの決定
↓
それぞれのデータの持つアトリビュートの決定
↓
エンティティ同士のリレーションの決定
↓
データを実際にデータベースのテーブルとして定義
上記に関する用語で新しく学習した用語一覧は下記になります。
●エンティティ
サービスの中で管理する必要のある情報や概念の事
エンティティの属性の事
例えば、SNSなどのサービスではユーザーや投稿内容などの情報がエンティティにあたるものでユーザーの持つ名前や年齢等はアトリビュートになります。
●リレーション
エンティティとエンティティとの間に存在する関係性の事
例えば、SNSサービスにおけるエンティティであるユーザーと投稿内容に関しては関係性があると言えます。
他にもデータベース設計に際して理解するべき基本的な用語を列挙します。
●主キー primary_key
テーブル内のレコードを判別するための識別子となるカラム
例えば、idという名前のカラムが主キーにあたる場合が多い
●外部キー foreign_key
異なるテーブルのレコードと関係性を持つ場合に必要なカラム
他のテーブルのレコードを識別するために使用する
railsにおける外部キー制約が付いているカラムの作成を行う場合には、
基本的にreference型を使用する方が楽！
※使用しない場合にはforeign_key: trueで外部キー制約にならない
その為、addで別に記述する必要性があるが、コードが多くなってしまう
また、外部キー制約をつける場合、インデックスは自動で付与されるらしい(未確認)
●not null 制約 null: false
テーブルの属性値にNULLが入ることを許さない制約
●一意性制約 unique
一意性とはユニークで他とは違うという意味で、一意性制約を設定した
カラムには同じ値を設定できなくなる
●インデックスの設定 add_index
データベースの機能の一つで、テーブル内のデータ検索を高速化すること可能
インデックスはカラムに対して設定することができ、設定したカラムでの
検索が高速になる
明日は実際にデータベースを設計するためのユースケース図とER図に関して学んでいきたいと思います。
時間に余裕があれば実際に書いて設計も進めていければと思います。
最後までお読み頂き有難うございます。
