Techcamp 転職 参加の記録

73期 2020年3月9日開始

3月31日(火)16日目

f:id:AOKITAKESHI:20200331224909p:image

今日は13時から研修だかでメンターさんに質問できない日だった。よりによってノーヒントでの実装課題に当たってしまったが、21時50分に突破することができた。

問題はchatspaceのmain headerにログイン中のグループ名とそのグループの参加メンバーを表示するというもの。

一見すると表示だけだから簡単そうだったが難しかった。

結局、コントローラーに定義してある@goupと@userをeachで羅列して解決した。@が分かるまでチートシートを見ながら何度もMVCの中を行ったり来たりしたが、うまく動いた時にはとても達成感があった。

 

3月30日(月) 16日目「課題アプリのユーザー管理の実装」

ユーザー管理実装のステップ

Devise Railsで作成したアプリケーションへ簡単に認証機能を実装することができるgem(ライブラリ)の一つ

gem 'devise’を記入

% bundle install

% rails g devise:install


Userモデルを作成

% rails g devise <モデル名>

※”rails g model user”で作るのは誤り


作成されたマイグレーションファイルに、

t.string :name, null: false 

 add_index :users, :name, unique: true

を追記、これでマイグレーション実行時にnameカラムがNOT NULL制約・一意性制約付きで作成される。

validates 

NOT NULL制約では空の文字列は保存可能なため更にuser.rb に 

validates :name, presence: true

と追記し、空の文字列の場合もエラーが発生する様にする。

最後にマイグレーションを実行

rails db:migrate


rails gコマンドの誤り

rails d model user

マイグレーションファイルの誤り

rails db:rollback


deviseのViewファイル設定

ダウンロードしたViewファイルの「devise」および「users」フォルダをapp/viewsフォルダに移動

「user.scss」のファイルをapp/assets/stylesheets/modulesに移動

app/assets/stylesheets/application.scssに@import "modules/user";


サインアップ機能の追加

デフォルトのユーザー登録は、「メールアドレス」および「パスワード」、そこへ「名前」も追加したい

application_controller.rbを編集

Railsでは、悪意のあるユーザーの入力に対してセキュリティ対策を行わないと保存できない


class ApplicationController < ActionController::Base

  protect_from_forgery with: :exception

  before_action :authenticate_user!

  before_action :configure_permitted_parameters, if: :devise_controller?


  protected


  def configure_permitted_parameters

    devise_parameter_sanitizer.permit(:sign_up, keys: [:name])

  end

end


上のコードは、deviseの公式サイトで紹介されている書き方

最後の3行でメソッド定義している。deviseのインストールでpermitメソッドが使え、これがストロングパラメータに該当する機能。

サインアップ時に入力された「name」キーの内容の保存を許可する。

deviseを使ったモデルはストロングパラメータではダメ。


ユーザー情報編集機能の追加

コントローラー作成

% rails g controller users


ユーザー情報編集機能を実装

routes.rb

# ルーティングを追加

Rails.application.routes.draw do

  devise_for :users

  # 下の行は削除する

  # get 'messages/index


  root "messages#index"

  resources :users, only: [:edit, :update]

end

users_controller.rb

class UsersController < ApplicationController


  def edit

  end


  def update

    if current_user.update(user_params)

      redirect_to root_path

    else

      render :edit

    end

  end


  private


  def user_params

    params.require(:user).permit(:name, :email)

  end

end


views/messages/_side_bar.html.haml

.side-bar

  .header

    %h3.header__name

      = current_user.name


      %li.list

        = link_to edit_user_path(current_user) do

          = icon('fas', 'cog', class: 'icon')


ログアウトのリンク作成

app/views/users/edit.html.haml

      = link_to "ログアウト", destroy_user_session_path, method: :delete, class: 'btn'


フラッシュメッセージが表示されるようにしよう

メッセージ用のビューを追加

「views/layouts」フォルダの中に、「_notifications.html.haml」を作成

.notification

  - flash.each do |key, value|

    = content_tag :div, value, class: key

flashオブジェクトの使い方

flashオブジェクト内には、複数のメッセージがハッシュのように「キー」「バリュー」形式で保存されている

each文を使うと、これらを1つずつ取り出すことができる


app/views/layouts/application.html.haml

  %body

    = render 'layouts/notifications'

    = yield

フラッシュメッセージのスタイリングを行おう

「stylesheets/config」に、「colors.scss」を作成

$white: #fff;

$side_blue_dark: #253141;

$side_blue_light: #2f3e51;

$light_blue: #38AEF0;

$light_gray: #999;

$black: #434a54;

$alert_orange: #F35500;


「stylesheets/modules」に「flash.scss」を作成

.notification {

  .notice {

    background-color: $light_blue;

    color: $white;

    text-align: center;

  }


  .alert {

    background-color: $alert_orange;

    color: $white;

    text-align: center;

  }

}


app/assets/stylesheets/application.scss

@import "reset";

@import "config/colors";

@import "modules/messages";

@import "font-awesome-sprockets";

@import "font-awesome";

@import "modules/user";

@import "modules/flash";

※colors.scssは、reset.scssの直後で読み込むようにしないとエラーが出る


日本語化用のファイルを作成

「config/locales」に、「devise.ja.yml」および「ja.yml」を作成

以下をそれぞれコピぺ

https://github.com/tigrish/devise-i18n/blob/master/rails/locales/ja.yml

https://github.com/svenfuchs/rails-i18n/blob/master/rails/locale/ja.yml

 

ChatSpaceにグループの新規作成・編集機能を実装

rails g controller groups

app/controllers/groups_controller.rb

class GroupsController < ApplicationController


  def new

  end


  def create

  end


end

config/routes.rb

  resources :groups, only: [:new, :create]


モデルを作成(多対多)

% rails g model group

% rails g model group_user


db/migrate/******_create_groups.rb

      t.string :name, null: false

      t.index :name, unique: true


db/migrate/******_create_group_users.rb

      t.references :group, foreign_key: true

      t.references :user, foreign_key: true


% rails db:migrate

! rails gで新しいモデルができる→マイグレーションファイルが新しいモデルの仕様書、編集する→マイグレーションすると新しいデータベースができる。


多対多のアソシエーションを設定

アソシエーションとバリデーションの設定

app/models/group.rb

class Group < ApplicationRecord

  has_many :group_users

  has_many :users, through: :group_users

  validates :name, presence: true, uniqueness: true

end


/models/group_user.rb

class GroupUser < ApplicationRecord

  belongs_to :group

  belongs_to :user

end


/models/user.rb

  has_many :group_users

  has_many :groups, through: :group_users

end


データを保存してみよう

$ pwd

# chatSpaceのディレクトリにいることを確認

$ rails c

$ Group.create(name: "グループ1", user_ids: [1, 2])

! Groupという親要素を保存するときに、user_idsで所属させたいユーザーを配列で指定するとその情報が中間テーブルに保存される仕組みになっている。

 

保存機能を実装

「collection_check_boxes」というヘルパーメソッドを使う


スタイルシートを適用

https://dl.dropboxusercontent.com/s/whd7ri0pd1h1tgn/group.scss?dl=1

@import "modules/group";


ビューファイルを編集

app/views/groups/new.html.haml

=form_for @group do |f|

  = f.text_field :name, class: "chat-group-form__input", placeholder: "グループ名を入力してください"

  = f.collection_check_boxes :user_ids, User.all, :id, :name

  = f.submit "Save", class: "chat-group-form__action-btn"


Groupsコントローラーを編集

class GroupsController < ApplicationController


  def new

    @group = Group.new

    @group.users << current_user

  end


  def create

    @group = Group.new(group_params)

    if @group.save

      redirect_to root_path, notice: 'グループを作成しました'

    else

      render :new

    end

  end


  private

  def group_params

    params.require(:group).permit(:name, user_ids: [])

  end

end


redirect_toとrender

redirect_to → ルーティング → コントローラー → ビュー

render → ビュー

元のインスタンス変数の値が上書きされるかどうかが違う

?(@groupという変数にはエラーメッセージが代入されているため、これが上書きされないようrenderによってビューを表示させる必要がある)


グループの編集機能を実装

config/routes.rb

  resources :groups, only: [:new, :create, :edit, :update]


app/controllers/groups_controller.rb

  def edit

    @group = Group.find(params[:id])

  end


  def update

    @group = Group.find(params[:id])

    if @group.update(group_params)

      redirect_to root_path, notice: 'グループを更新しました'

    else

      render :edit

    end

  end


新規作成

app/views/groups/edit.html.haml

= form_for @group do |f|

  = f.text_field :name, class: "chat-group-form__input", placeholder: "グループ名を入力してください"

  = f.collection_check_boxes :user_ids, User.all, :id, :name

  = f.submit "Save", class: "chat-group-form__action-btn"

 

メッセージ送信機能を実装

メッセージモデルを作成する

% rails g model message

class CreateMessages < ActiveRecord::Migration[5.2]

  def change

    create_table :messages do |t|

      t.string :content

      t.string :image

      t.references :group, foreign_key: true

      t.references :user, foreign_key: true

      t.timestamps

    end

  end

end

% rails db:migrate

app/models/message.rb

class Message < ApplicationRecord

  belongs_to :group

  belongs_to :user


  validates :content, presence: true, unless: :image?

end

app/models/group.rb

  has_many :messages

app/models/user.rb

  has_many :messages


group_idとuser_idはreferences型で設定してあるので、カラム名に_idは不要。その2つのカラムには外部キー制約を。

3月27日(金)15日目 「課題:ChatSpace app のフロント画面実装」

f:id:AOKITAKESHI:20200328113343j:plain

アフターコロナの世界で、Webエンジニアは社会のあらゆる場所で仕事をし、日々何かを生み出していく。変わらざるを得ないから追われるように仕事をするのは悲しい事だ。しかし当面は仕方が無いかもしれない。でも、ビルやスティーブが僕らの日常を変えたように、エンジニアはきっとワクワクする未来を作っていける職業だ。今日も頑張ろう。

 

さて、今日もブログを書くのが翌日の昼になっている。昨日3月27日(金)は1日中集中して課題のフロント画面をhamlとsassで書いていたが結局1日かけても終わらなかった。自分はまだあまりにも無力、しかしこれを乗り越えて一つ成長できる。そういう着実な積み重ねを数えながら亀の上に乗ったカタツムリのごとく進んでいきたい。生憎とコロナで土日は不要不急の外出自粛である。女性を危険に晒すわけにいかないのでデートはキャンセルである。何とつまらなく味気のない世界なのか。こんな時世界を作り変える技術があったらどんなものを生み出せるだろうか。テレビ電話はデートじゃないんだ、それじゃないんだよ。えーとこう・・・よし、頑張ろう。

3月26日(木) 14日目 「SassとHaml」

 ブログ更新が翌日の朝になっている。というのもSassとHamlの勉強をしていたが、何ともコロナのニュースが煩過ぎて全く集中できず、夕方に中断して一旦情報収集と分析を行った。まず、東京の感染者が25日に41人、26日昼時点で45人と日本での増加率が過去最高になったという事。そして小池都知事の土日外出自粛要請を皮切りに埼玉千葉神奈川が東京への県民の外出自粛要請を出した。結果東京のスーパーで生鮮食品の品切れが起きるなど軽いパニックになり、夕方にはTECHCAMPでも土日の休校アナウンスがあった。

 我慢ならなかったのは「昨日オリンピックの延期が決まったので国が隠していた感染者を発表した」という妄言がそこかしこで飛び交っていた事だ。あまりにも幼稚で稚拙な根も葉もない噂に腹の虫が暴れてしまい勉強が手につかなくなった。

 私が見ていた限りの自治体公表の数値では世界と比較して日本の感染者率は依然として驚くほど低い。アメリカイタリアが一気に5万人を突破していき欧州諸国で軒並み1万人を超えていく中、日本は1200人、日毎の増加数も数十人程度だった。検査数の少なさを指摘する声も多いが感染者数が増加したら検査数が増加するんであって、その逆ではないということと、死亡者数はどうやっても誤魔化せないということ、何よりも仮に感染者数を隠していたとして40人ずつ毎日発表することに一体どんな政治的根拠があるんだろうか。歴史の教科書にどんなふうに載るか考えない政治家がいるとでも。。

 そんなことを思いながら、再度一次情報の数値と専門家の意見を収集した。その結果分かったのは、小中高の停止を受けて当時の感染者が100に満たなかった米国へ、またヨーロッパの安全と思われた国々へ避難を兼ねて渡航した家族旅行者が3月の10日前後に帰国しており、それらの方々が潜在的なキャリアになっている可能性のあること。また、それらを含めて、東京においての濃厚接触のあったクラスターが20を超えていること。それらの今現在の実際の感染状況が数字で上がってくるのに、最長後2週間を要する事。それが小池都知事の4月8日までの外出自粛の根拠らしい事、そんな事が分かった。

 恐らく、来週の月曜あたりの感染増加数と1週間後の来週金曜日までの増加率を見ればある程度の予想はつくだろう。首都閉鎖になるのなら、目に見えて明らかな数字が1週間で出るはずであり、またそうでない場合はあまりに想定外の感染経路でもない限り2週間後の数字も大差ないはずであろうと思っている。

 

 

本日の勉強

復習ドリル

mixin

&(アンパサンド)

BEM

ERB

haml

 

 

Sass

 

変数が使える。 $から始める

変数名: 値;

$section-color: rgb(30,30,30);

section {

  background-color: $section-color;

 

パーシャル Sassファイル

ファイル名を_(アンダースコア)から始める

読み込むには、@import “ファイル名” と記述

@import "reset";  /* _reset.scssを読み込む */

@import "header"; /* _header.scssを読み込む */

 

変数を別ファイルに定義して使う

定義するファイル、

_variable.scss (ファイルを作る)

$mainYellowColor: #FFEC00;

 

mixin まとまったスタイルを定義 @mixin mixin名() {}

_clearfix.scss (ファイルを作る)

@mixin clearfix() {

  &:after {

    content: '';

    display: block;

    clear: both;

  }

}

 

&(アンパサンド) 擬似要素であるafterが適用されているセレクタ

 

 

BEM

CSS設計、厳格なクラスの命名規則が特徴。

Block、Element、Modifierの頭文字で、ページを構成する要素をBlock、Element、Modifierのどれかに当てはめてクラスを命名する

 

Block

大元となるブロック要素。Blockの命名には名詞を使用。

Element、Modifierは、このBlockを起点に命名

 

Element

Blockに属する子要素です。1つ以上のElementによって、Blockは構成される。

Elementの命名には名詞

 

Modifier

Blockまたは、Elementに特別な修飾をする要素。Modifierの命名には形容詞

 

  • BlockとElementをつなぐ場合は、アンダースコア2つでつなぐ
  • Modifierにつなぐ場合は、ハイフン2つでつなぐ

 

sample.html

<nav class='HeaderNav'>

  <ul class='Menu'>

    <li class='Menu__list'>TOP</li>

    <li class='Menu__list'>CONTACT</li>

    <li class='Menu__list Menu__list--backBlack'>ABOUT US</li>

    <li class='Menu__list'>SERVICE</li>

   </ul>

</nav>

 

&(アンパサンド)で階層にする

sample.scss

.Menu {

  list-style: none;

  &__list {

    background-color: #3BD1EC;

    color: #FFF;

    float: left;

    font-size: 30px;

    padding: 2% 1%;

    text-align: center;

    width: 23%;

    &--backBlack {

      background-color: #000;

      color: #3BD1EC;

    }

  }

}

 

 

ERB クラスを使うためには require 'erb' する必要があります。

require 'erb'

ERB.new($<.read).run

 

Haml HTMLよりも簡単に書くためのビューテンプレートエンジン。.html.erbではなく.html.haml

gem 'haml-rails'

bundle install

rails haml:erb2haml  #変換 erb → haml

 

3月25日(水) 13日目 「データベースの設計」

引き続きSQLのコードから

 

sequel pro に直接コードを打ってデータ検索をする

クエリタブを選択

select *

from users

データテーブルの検索 selectがカラム名 fromがテーブル名

select family_name

from users

e.g.family_nameカラムの取り出し。

※命令文は1行目から書き直す必要がある

 

ワイルドカード

文字の代わりとして使うことが出来る記号。SELECT句においては、アスタリスクが"全てのカラムを取得する"という意味のワイルドカードとして定義がされている

 

レコードの取得

WHERE id = 1

WHERE family_name = "阿部"

WHERE id <= 5

 

select *

from users

where family_name = "阿部"

e.g.阿部レコードのみを取得

 

where句

AND演算子が使える

 

SELECT *

FROM users

WHERE age <= 22 AND prefecture = "神奈川県"

 

or演算子

SELECT *

FROM users

WHERE age <= 20 OR prefecture = "東京都"

 

NOT演算子

SELECT *

FROM users

WHERE NOT prefecture = "東京都"

 

BETWEEN演算子(<= and =>) 上限下限を指定

ハイフン二つでコメント

SELECT *

FROM users

WHERE age BETWEEN 21 AND 24

-- ageが21以上かつ24以下

 

IN演算子(or)

1つのカラムに対しリストを指定して、カラムの値がそのリストに含まれるとき、その式は正になる

SELECT *

FROM users

WHERE prefecture IN ("東京都", "神奈川県")

prefectureが東京都か神奈川県を表示

 

CNCAT関数

SELECT CONCAT(family_name, first_name)

FROM users

複数の文字列をつなげる※繋がって一つのセルで表現される。別からむで出力は以下

SELECT family_name, first_name

FROM users

AS句

カラム名に別名をつける※↓”AS”は省略可能、書かなくて良い

SELECT CONCAT(family_name, first_name) AS "名前"

FROM users

 

DISTINCT 重複削除

SELECT DISTINCT user_id

FROM shifts

WHERE date = "2015-07-01"

 

GROUP BY 指定カラムの同じデータをグループとしてまとめる ※結果は上記と同じになるが、集計のされ方が異なる

SELECT user_id

FROM shifts

WHERE date = "2015-07-01"

GROUP BY user_id

 

COUNT関数 指定カラムを全て数える。以下のようにGroup by 併用の場合はグループ数を数える。以下ではASをコマ数としている。

SELECT user_id, COUNT(*) "コマ数"

FROM shifts

WHERE date = "2015-07-01"

GROUP BY user_id

 

JOIN 別のテーブル情報の結合 FROMの後に記述。

E.g.テーブル名2 ON テーブル名1.カラム名1 = テーブル名2.カラム名2

※JOINにはLEFT JOINやRIGHT JOINもある。

 

↓ASで短くできる

FROM shifts s

JOIN users u ON s.user_id = u.id

SELECT user_id, COUNT(*) "コマ数", u.* —u.*はuserテーブルの全ての情報を取得するという意味

FROM shifts s

JOIN users u ON s.user_id = u.id

WHERE date = "2015-07-01"

GROUP BY user_id

SELECT CONCAT(family_name, first_name) "名前",COUNT(*) "コマ数"

FROM shifts s

JOIN users u ON s.user_id = u.id

WHERE date = "2015-07-01"

GROUP BY user_id

最終的に、名前でシフトのコマ数が取得できた

 

サブクエリ ある検索結果を使用して別のSQL文を実行する仕組

NOT IN それ以外

 

以下では"2015-07-01"にシフトに入っていない人の一覧を取得

SELECT *

FROM users

WHERE id NOT IN (

    SELECT DISTINCT user_id

    FROM shifts

    WHERE date = "2015-07-01"

)

セレクト文を全て取得し、user_idの重複削除を取得

 

 

 

データベース設計

要素は以下の3つ。

  • サービスで扱う概念(エンティティ)
  • エンティティの属性
  • エンティティ同士の関係性(リレーション)

 

エンティティ

例えばSNSでは「ユーザー」や「投稿内容」、「コメント」

 

必須となる手順は以下の4つ

  1. データベースで管理するデータ(エンティティ)を決める
  2. それぞれのデータの持つ属性を決める
  3. エンティティ同士の関係性を決める(リレーション)
  4. データを実際にデータベースのテーブルとして定義する

 

エンティティはテーブルに相当し、属性はテーブルが持つカラムに相当

 

キー

テーブルにおけるキーとはレコードを識別するための特別なカラム

主キー

多くの場合ID

外部キー

他のテーブルのレコードを識別する。例えばこのテーブルIDとは別のカラムで他のテーブルのIDと対応する数字(ID)など

 

rails g model テーブル名

モデルテーブルをターミナルから作成

 

制約 バリデーション

設定できる制約の中で主なものは以下の4つです。

  • NOT NULL制約

      マイグレーションファイルのdef change のcreate_tableへ記述後マイグレーション→ t.string :name, null: false

 

  • 一意性制約

重複データ禁止制約     

% rails g migration AddEmailToUsers email:string

add_indexメソッドの中でunique: trueという引数を指定することで、一意性制約をかけるためのマイグレーションファイルを作成できる

マイグレーションファイルのdef change へ追加 add_index :users, :email, unique: true

 

  • 主キー制約

主キーである属性値が必ず存在してかつ重複していない ※RailsではIDカラムが元々この制約を持っている

 

  • 外部キー制約

外部キーの対応するレコードが必ず存在しなくてはいけないという制約

作成したマイグレーションファイルのdef change のcreate_tableへ記述 t.references :user, foreign_key: true

 

 

インデックス

テーブル内のデータの検索を高速にするための仕組。カラムに設定するとそのカラムの検索が高速化する。

デメリット

  • データを保存・更新する速度が遅くなる
  • データベースの容量を使う

 

マイグレーションファイル

def change

    add_index :テーブル名, :カラム名

複数カラムへのインデックス

add_index :テーブル名, [:カラム名, :カラム名]

 

 

正規化

データベースのデータ構造をより効率的で重複や無駄のないシンプルな構造にするための手順

正規化を行ったあとのデータベースの構造を正規形という。反対は非正規形。

 

正規化は段階を踏む

非正規形

第一正規形

テーブル内に繰り返されるレコードをなくすこと

第二正規形

第三にほぼ同じ?

第三正規形

属性ごとにテーブルを分ける。e.g.一つのテーブルだったものを生徒テーブル、授業テーブルにきり分けるなど

(ボイスコッド正規形、第四正規形、第五正規形)

第三で終える事がほとんど。デメリットが大きい、小さいテーブルが増えるので遅くなる。

 

 

(課題

Id student class class_teacher lesson1 Lesson2 lesson1_score Lesson2_score

上記計8カラムのテーブルを切り分ける

以下の5テーブルになる

studentsテーブル 外部キーhomeroomeを持つ

Teacherテーブル 外部キーhomeroomeを持つ

homeroomsテーブル 主キー+ホームルームネイむ

subjectsテーブル 主キー+科目名

scoresテーブル 外部キーsubject_idを持つ

※ER図を書いた際

一対多の関係のときに外部キーを設定する。

 

 

中間テーブル

has_many throughオプション

中間テーブルをスルーするが外部キーはもらうという意味

  has_many :中間テーブル名

  has_many :多対多のテーブル名, through: :中間テーブル名

※しっかりと中間テーブルともアソシエーション を組む事

 

マークダウン 文書を記述するための軽量マークアップ言語のひとつ。記述されたものは、HTMLに変換される。

 

 

 

復習ドリル ~Explain the definition and make an example sentence.~

 

ワイルドカード

※JOINにはLEFT JOINやRIGHT JOINもある。

サブクエリ

データベース設計

エンティティ

キー、主キー外部キー

インデックス

正規化の段階

中間テーブル、thtoughオプション

3月24日(火) 12日目 webアプリケーションの開発にあたって

 

 


GitHub flow

これに沿って開発するのが一般的である。カリキュラムもGitHub flow に則る。

1.masterブランチのものは何であれデプロイ可能である

2.新しい何かに取り組む際は、説明的な名前のブランチを master から作成する

3.作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定期的に作業内容を push する

4.フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、プルリクエストを作成

5.他の誰かがレビューをして機能にLGTM( OK )出をしてくれたらmasterへマージすることができる

6.レビューを経てマージをしたら、直ちにデプロイをする

 


デプロイ

アプリケーションをサーバー上で公に利用可能な状態にすること

 


デプロイと GitHub

デプロイをする際には、GitHub を介して行うと便利。

GitHub のマスターブランチのみがサーバー側に反映されるようにデプロイする。

何か新機能を加えたい時や修正をしたい時は以下で行うと稼働中のサービスを長時間止める事なくアップデートできる。

ブランチを作成
コード変更修正
動作確認
マージ
サーバー側に pull デプロイ

 

コンフリクト あるファイルにおいてブランチごとに情報が異なり辻褄が合わない状況のこと

 


git revert

コミットを打ち消すコミットを生成する操作が行なえる。

gitにおいて、プッシュした情報をローカルリポジトリに戻すことはできないため、プッシュする前に作業をしているブランチは正しいのかどうか、必ず確認する

それでも誤ったプッシュをした場合は、git revert

 


コミットの注意点

コミットはなるべく細かく行うべき。1機能1コミットをするのがベター。基本的にファイルを元に戻したいと思ったときには、コミットごとでしかファイルを元に戻すことが出来ないため。

 


プッシュ

ローカルリポジトリで加えた変更とリモートリポジトリに同期させること。ローカルでコミットが終わり、リモートに変更を同期させたい場合には必ずプッシュを行う必要がある。

 


プル

リモートリポジトリの変更履歴をローカルリポジトリに反映させる操作のこと。

他の開発者による変更がリモートリポジトリに反映された後や、自分でマージを行った際には必ずこのプルの作業を行う必要がある。

 


競合(コンフリクト

複数の人が同じ箇所を編集してしまい、変更箇所を自動では判断できすにマージできなくなること。

競合が起きる条件は、2つのブランチで同じ箇所のソースコードを編集した際、片方のブランチをマージし、もう片方のブランチを同じブランチにマージをするという2つの条件が起こったときに、競合は発生する。

 


.gitignore
gitの管理対象から管理を外すためのファイルやディレクトリを指定するためのファイル。.gitignoreにファイルやディレクトリを指定すると、管理対象から外すことができる。
管理対象から外れるということは、githubにコードやファイルを同期させなくて済むということ。
- アプリケーションのlogファイル
- 画像ファイル public/uploads 以下
- secrets.yml 等のセキュリティ上問題があるファイル
このようなファイルを主にgitignoreに指定する。
これ以外にも、自分でgithubで公開したくないファイルも自分で指定できる。

 


/log/*

という記述が.gitignoreのファイルにあったら

logファイル以下のファイル、ディレクトリをgitの管理下から除外を行う指定を行っている。

 

 

 

ChatSpace

ChatSpaceを実装することで、身につくスキル

Webサービスの開発全体の流れの把握
GitHubを用いたサービス開発フロー
ゼロからのデータベース設計
Railsを使ったアプリケーション制作
javaScriptを使った動きのあるアプリケーション制作
サービスをWeb上に公開する方法

 

Webアプリケーション開発の流れ

企画
設計
開発
公開
(運用、保守)

 


Webアプリケーション開発手順

必要な機能の洗い出し
必要な画面の設計
データベースの設計
Railsでアプリケーションの雛形を作成
大きな機能から順に実装
テストコードを記述し動作を担保する
リファクタリングによりソースコードを整理する
外部のサーバにサービスをアップして公開する

 

コミットメッセージの書き方(まとめ)

書く上で心がけること
- 後で見て、コードを見なくても何をしたか分かるように書く
- 他人が読むものとして書く
- 長くなりそうだったら改行して何行書いても良い

 


SQL

ますはターミナルで操作

% mysql -u root

Mysqlにルートで接続する

Show databases;

作成済みのデータベースを参照する

create database 名前;

新しいデータベースを作成する

use データベース名

選択する

show tables

データベースの中を見る

CREATE TABLE テーブル名 (カラム名 カラム名の型, ……);

 


Railsでは数字を入れる型は"Integer"、文字列を入れる型は"String"だった

 


型名
保存できる値
INT
数字
VARCHAR(M)
最大M文字の文字列
e.g.

create table goods (id int, name varchar(255));

 


show columns from goods;

テーブル構造の確認

 


alter table goods add (price int, zaiko int);

e.g."price"と"zaiko"という2つのカラムを、共に"int"型で作成

 


修正

ALTER TABLE テーブル名 CHANGE 古いカラム名 新しいカラム名 新しいカラムの型;

alter table goods change zaiko stock int;

e.g."zaiko"→"stock”へ変更

 


削除

alter table goods drop stock;

e.g.”stock”の削除

 


登録

Insert

・全てのカラムに値を入れる場合

INSERT INTO テーブル名 VALUES(値1, 値2, 値3);

・特定のカラムのみに値を入れる場合

INSERT INTO テーブル名(カラム名1, カラム名2) VALUES(値1, 値2);

 


insert into goods values(1, "ペン", 120);

全てのカラムに値を入力する

 


SELECT * FROM goods;

全てのテーブル情報を表記する

 


insert into goods(id, name) values(2, "消しゴム");

特定のカラムにのみ入力する

 


更新

update goods set price = 100 where id =2;

ID2のpriceに100を入力

 


削除

delete from goods where id = 2;

ID2の行削除

3月23日(月)11日目 応用カリキュラム初日

今日はGitHubについて勉強した。

Gitはプログラムのセーブポイントのようなものらしい。また、GitHubはオンラインで複数人が同時に作業をするときに使う。

リポジトリという箱を作り、ローカルの場合は自分おPC、リモートリポジトリというのがGitHubで使うオンラインの箱。

% git init でリポジトリを作成する。

リポジトリの中にはインデックスがあり、変更修正したデータをバージョン記録と共にインデックスへ追加する。

% git add コマンドでリポジトリのインデックスへ変更修正データを追加、その際「.」をつけることで「全て」の意味になる。

% git add .

そしてインデックスに追加されたバージョンはコミットコマンドでgitに記録される。

% git commit

% git log でコミットの履歴確認ができる。

まとめると

% git init

% git add .

% git commit

% git log

 

次にGitHubを使う場合、ローカルリポジトリとリモートリポジトリの紐付けを行う。

% git remote add 紐付け

% git push origin master pushでオンラインにアップ?する

 

GitHubの手順をまとめると

% git add .

% git commit -m 'replace the massage'(' ~ 'の部分はコミットメッセージの付与)

% git push origin master

 

ブランチという概念について

共同作業を行う場合、masterブランチとトピックブランチに分けて作業を行う。

masterはリポジトリに最初のコミットを行うと自動作成される大元であり、通常は実装する作業毎にトピックブランチを作成するなどして分割作業を行い、完成後にmasterブランチに統合する。

 

プルリクエスト 1つのブランチでの作業についてコミュニケーションが取れる掲示板のようなもの

トピックブランチの作成 対象ブランチで少なくとも一回の新規コミットをしなければならないので、作業前であれば以下のコマンドで空のコミットを作る

% git commit --allow-empty -m 'create pull request'

 

プルリクエストのタイトルには[WIP]をつける。Work in progress(作業中)。終わったら外す。

プルリクエストの詳細にはWhat(何をするか) とWhy(何故するか)を書く。

 

GitHubの操作はGUIであるGitHub Desktopというappが便利なので用いる。