Sakiのプログラミング学習ブログ

プログラミングについて学んだことや、学習の振返りを書いています。

データベースに関する用語まとめ

データベース

✧ データベースとは

  • 整理されたデータのまとまり
  • 大量のデータをコンピュータシステム上で扱えるように集めたもの
  • 大量とはエクセルで管理できるレベルでなく、数千万件、数十億件の数

データと情報のちがい

  • データとは:事実のみを指す。あるフォーマットに揃えられている。
  • 情報とは:データを部分的（全体の場合もある）に収集、加工したもの
  • 天気予報で例えると、
    • データは観測側で決めた数値を観測したもの
    • 情報は、そのデータを用いて晴れの確率、雨の確率を導き出したもの。普段ニュースで見ている天気予報はこっち。

✧ リレーショナルデータべース(RDB)とは

  • データを表形式で扱うデータベースのモデル
  • 他にも様々なデータベースのモデルがあるが、プログラマーを目指すなら、まずはRDBをできるようになる必要がある

リレーショナルデータベースマネジメントシステム(RDBMS)とは

  • リレーショナルデータベースを便利に使うためのソフトウェア
    例：オラクルデータベース、MySQL、PostgreSQL

SQLとは

  • リレーショナルデータベース(RDB)を読み書きするときに使う言語

RDB, RDBMS, SQLの3つの関係

  • Postgresqlなどのリレーショナルデータベースマネジメントシステム(をSQLという言語を使って操作し、これによりリレーショナルデータべースデータベースを扱うことができる。

✧ リレーショナルデータべース(RDB)の設計

  • 以下より、リレーショナルデータべース(RDB)の設計=データベース設計と記載

設計は、システム開発のステップのどこに当たるのか?

  • 開発には4つのステップがある
    • 要件定義
    • 設計 ←リレーショナルデータべース(RDB)の設計はここに当たる
    • 開発
    • テスト
  • この4ステップのうちデータベース設計が当てはまるのは設計。 設計はデータベースだけを設計するのではなく、ユーザーが使用する画面の設計や機能を決めるアプリケーション設計など、他にも色々設計することがある
  • この4つをどう進めるかのやり方は主に2つに分かれる。
    ウォーターフォールモデルとプロトタイピングモデル(これを応用したのがアジャイル)

データベース設計の3つのステップ

データベース設計にも段階があり、3つのステップがある。
1. 外部スキーマ/ 2. 概念スキーマ/ 3. 内部スキーマ

1. 外部スキーマ

  • ユーザーから見たデータベース。画面のユーザーインターフェースや入力データなど。
  • 例えば、Twittterのアカウントのプロフィール画面では、ユーザー名(@から始めるID),表示名,自己紹介文,位置情報,ウェブサイトなどのURL,誕生日,いつからTwitterを使っているか,今フォローしている人数,今フォローされている人数,時系列順になったツイートの一覧,リプライも含めたツイート一覧,画像・動画がついたツイート一覧,いいね一覧,おすすめツイート,トレンドなど、ユーザーは様々なデータベースを見ることができる。

    このように、プロフィール画面に何のデータを表示するかや、データをどのように画面に表示するかなどを定義するステップが、外部スキーマである。

2. 概念スキーマ

  • データベースに格納するデータの洗い出し、そのデータ同士の関連性の定義を行う。
    = 論理設計という。
  • この「論理」とは、データベースサーバーのCPUパワーやストレージの格納場所など、物理層の制約にとらわれない設計ということを意味する。
  • データベース設計を行う時は、まずこういった物理層の制約は無視して先に論理設計を行う。
  • フィヨルドブートキャンプのTwitterのデータベース設計の課題はこれに当たる。

3. 内部スキーマ

  • 論理設計で定義されたデータを、具体的にどのようにリレーショナルデータベースマネジメントシステム(RDBMS)に格納するかを定義する。=物理設計という。

✧ 論理設計で出てくる用語まとめ

f:id:Saki-Htr:20210113070746p:plain
テーブルの見方
(データベースの用語を理解しよう 「テーブル」「レコード」「カラム」「フィールド」とは？より引用)

エンティティ/テーブル

  • エンティティとは、データの集合体。 例:顧客、会社、社員、店舗、車、注文履歴、税
  • リレーショナル・データベースでは、これを二次元表に近いテーブルという物理的な単位で格納して、データを表現する。

列(カラム,属性)

  • エンティティは、データを属性という形で保持する
  • 例えば、顧客というエンティティが持つ属性は、顧客の名前、生年月日、住所、電話番号など。

行(レコード,タプル)

  • 登録・管理されるデータそのものを指す。
  • 例えば、上記の顧客テーブルのレコードは、
    • 顧客の名前:山田花子
    • 生年月日:1990年1月1日
    • 住所:東京都大田区○○町1-1-1
    • 電話番号:03-1234-5678

この山田花子に関する実際のデータそのものを指す。

✧ 参考書籍/参考記事

週報 1/4(月)~1/10(日)

1/4(月)~1/10(日)の一週間の学習の振り返りをざっくり行った。

今週の目標&結果

今週の目標 結果
正規化ができるようになる ◯
TwitterのDB設計の課題を提出する △ 今週中に提出できず(1/11(月)に提出)

今週の学習時間

プラクティス外の学習・勉強会への参加は含めない。

日付 目標 実際
1/4(月) 2:00 3:15
1/5(火) 2:00 2:30
1/6(水) 2:00 1:15
1/7(木) 6:00 6:15
1/8(金) 2:00 3:30
1/9(土) 6:00 5:45
1/10(日) 6:00 5:30
合計 26:00 28:00

今週やったことや考えたこと色々

1/4(月)

1/5(火)

  • 演習問題１を解く
    • イベント系エンティティとリソース系エンティティの抽出
    • 項目(カラム)をテーブルに入れる
    • postgresqlで↑のテーブル作成
      • 忘れていたpostgresqlの操作を思い出した。登録したいものを実際に操作すると良いアウトプットになると思った。
      • テーブル作成でカラムを同時に複数する操作と、主キー,not nullの制約をつけたカラムを登録する操作に手間どり、時間がかかった。
  • 日報で質問した。エンティティを抽出した後正規化のやり方がわからず、想定される様々なレコードを登録してみて、どのカラムが主キーになるかや、どこに関数従属があるかを見つけて正規化しようと思っているが、方向性が合っているか聞いた。 →良いと思うと言っていただけた。設計してデータ入れてみたら矛盾に気づく事も多いらしい。
  • 6:00~7:00 TeamGeek輪読会(第1回)

1/6(水)

1/7(木)

  • 昨日の日報提出
  • 演習問題1の自分で作ったテーブルに色んなレコードを登録してみる
  • 雑談ルームで質問
    • 自分で作った第1正規形の主キーが分からなくなった
    • 質問した際に、回答してくださった方が仰ったことと、それを聞いた自分の理解が同じかどうか確認する作業はとても大事だなと思った。前に、「質問は"このように理解しましたがあってますか？"だけでも十分です」とアドバイスされたことを思い出した。前回質問した時よりもそれができていて、話の認識がずれずに済んだと思う。
  • 非正規系→第3正規形まで正規化
  • 答えと違う点を整理して質問
  • この前質問した時よりも、DB設計の理解が進んでいると褒められた。嬉しい。
  • 「達人」と「楽々」で正規化する前のテーブルの状態がちがうので、とまどった。 達人は一つの大きなテーブルにすべてのカラムが詰め込まれている。楽々はイベント系エンティティとリソース系エンティティに分けている。 →達人のやり方のほうでやったほうがいいとアドバイスいただいた。
  • エンジニアの重要な仕事は「ビジネス側へのヒアリング」と「言語化」なので、身につけるべき知識だと教わる
  • 6:00~7:00 TeamGeek輪読会(第2回)

1/8(金)

  • 自分が作った第3正規形と楽々の答えの違いを整理して昨日の日報で質問
  • TwitterのDB設計に取り掛かる
    • Q&Aや参考記事を読んだ
    • 機能の洗い出し(途中)
  • この日は仕事後集中できずPCに向かっていても、ぼーっとしてしまったので、課題を進めるのは諦めて、ブログを書くか後回しにしていた庶務をやった方が良かったかも。

1/9(土)

  • Twitterの機能洗い出し
  • 機能ごとにテーブルを作り、各テーブルに項目(カラム)を入れてみる
  • 項目を入れるところでミュート・ブロック・いいね・リツイート機能などのテーブルに、どういったカラムを入れればよいのか行き詰まり、中間テーブルと自己参照が必要なことに気がつけた]
  • 6:00~7:00 TeamGeek輪読会(第3回)
  • 14:15~14:45 達人に学ぶDB設計の輪読会の予習
  • 22:00~23:00 達人に学ぶDb設 輪読会(第2回)
    • 1回目よりは積極的に参加・発言できた
    • なんとなく理解していたスキーマが3層である理由がわかった。
  • twitterのDB設計ができるか不安なのと、寒いせいかぼーっとしてしまいなかなか学習に入れなかった。 分からないことを理解するという行為そのものよりも、分からなかったらどうしようという不安が私にとってハードルになっている。 書籍や参考記事を読む中で理解することができてきた(少なくとも課題はクリアした)、という成功体験を積んできたはずなのに、分からないことへの不安・恐怖になかなか慣れないなと感じる。

1/10(日)

  • 多対多、中間テーブル、自己参照/自己結合の理解
    • 中間テーブルを理解できた!想像していたよりも難しくなくてホッとした。自分で中間テーブルを作って登録してみると理解が深まってよかった。
    • 自己参照/自己結合は、完全には理解できなかった
  • ER図の見方を少し忘れていたので復習
  • 一週間ごとの週報ブログのフォーマット作成
  • 中間テーブル、自己参照/自己結合をtwitterのDB設計の課題に組み込んだ。

今週の振り返り

✅ できたこと/できるようになったこと

  • postgresqlの操作に慣れた
  • 今週に課題提出するという目標を設定していたので、今質問しないとタイムロスになるという思考が働き、どんどん質問できた。
    • 質問を日報で2回、雑談ルームで1回した
  • 正規化を理解はしているが実践はできてない状態から課題提出まで行けた
  • 自分で作ったテーブルにレコードを登録してみたら正規化の理解がとても深まった
  • TwitterのDB設計をかなり進められた
  • 多対多、中間テーブルを理解した
  • 自己参照/自己結合を完全には理解できていないが、課題に組み込めるレベルまでは理解できた
  • 目標学習時間を上回った

    ✅ "こうしたらもっと良かった"と思うこと

  • テーブルへのレコード登録と課題作成にあたって、Postgresqlを使う必要がなかったので、タイムロスだった。 (しかし後のプラクティスで絶対操作することになるので、慣れられたのはよかった)
  • 目標は明確だったが、やることの内訳は不明確だった(DB設計の手順の理解が難しかったのもあり、明確にできなかった)
  • 仕事後の集中できない時間は、課題作成ではなく、ブログを書くか後回しにしていた庶務をやった方が良かったかも。

    考えたこと

  • 家で学習するときは、スマホをタイムロッキングコンテナに入れたほうがずっと集中できることが分かった。
  • 睡眠の質確保のため、寝る前のカフェイン排除&入浴は必須と分かった
  • 意外と夜のほうが集中できることが分かったので、休日は無理に早起きしないことにした

来週の目標

DB設計の復習中心。

  • TwitterのDB設計を合格する
  • DB設計で学んだことをブログに書く
    • draw.ioの使い方備忘
    • 用語の整理
    • 正規化の手順
    • ER図の見方
    • DB設計の手順
    • 中間テーブル
    • 自己参照/自己結合
    • 自分がDB設計で理解につまずいた所&どうやって理解したか
      このあたりをまとめたい。

【初LT】 TECHPLAY女子部で初めてLT登壇しました

勉強会・イベント LT

f:id:Saki-Htr:20210912102642p:plain

はじめに

こんにちは。Sakiと申します。プログラマーを目指して、フィヨルドブートキャンプというプログラミングスクールで学習中です。今年中の卒業を目指しています。 1/2(土)に開催された、TECHPLAY女子部の「新春🌅 初夢 LT会」というイベントで、初めてLTをさせていただきました。

私は、『勇気を出してオープンな場で質問をしたら、考え方が変わった話』というテーマで発表させていただきました。

原稿はこちらです。

目次

開催概要

  • 1/2(土)6:00~7:30 zoomにて
  • 発表は1人5分
  • 発表者は5名
  • 最後の30分は雑談

開催の経緯

去年12/12にRails Girls Gathering JapanというLTイベントの発表をお聞きして、「私もLTをしたくなった」と、女子部の朝活チャンネル#hayaoki_girlsで話したところ、話を聞いてくださった方が「やりましょう!」と開催してくださることになりました。

まさかLTをしてみたいという夢がこんなにすぐに叶うとは思いもしませんでした。開催してくださった方には本当に感謝しています。ありがとうございました!

準備したこと

1. テーマ決め

はじめは、プログラミング学習について、去年の振り返りとそれを踏まえた今年の抱負を3つずつくらいで話そうと思っていました。
しかし、原稿を書いているうちに、「あれもこれも話したい」となり、5分では足りないと思ったので、「質問すること」という一つのテーマについて深堀りして話すことにしました。

発表内容が5分と短い分、「自分が本当に伝えたいことは何か?」を突き詰めて考えました。

2. 原稿

メモツールのesaが、個人的なメモに使う人も多いくらい人気だと聞いていたのと、マークダウンで書ける点が良いと思ったため、esaを使うことにしました。

スライドをめくるのを忘れてしまわないように、次に進めるタイミングの所に、📜 スタンプを目印として入力していました。 また、macbookの画面で原稿を見ながら、外部モニターに映したスライドを進めて発表するため、macbookの画面を間違えてクリックしないように「この画面を※クリックしない」と注意書きを冒頭に書いておきました。

3. スライド作成

フィヨルドブートキャンプの受講生の方のブログなどを参考にして、使うツールを決めました。スライドを作成するのは大学生の時以来で、PowerPoint以外にもたくさんの便利なツールがあることを知り、驚きました。 今回は、Marp for VS Codeという、VScodeにマークダウンで書くとそのままスライドにしてくれるツールを使って作成しました。

完成まではスムーズでしたが、完成したスライドをSpeaker DeckにアップロードするためにはPDF化しなければいけないことに気が付き、そこに苦戦しました。 以下の記事を参考にしてPDF化しました。

4. 発表練習

原稿が7割ほど完成したあたりから、5分で収まるか計りながら練習をしました。そこで、言い回しが分かりにくい点を修正したり、不要な説明を削ったりしました。 8回程練習をしながら原稿を完成し、本番環境で4回ほど練習をしました。

たくさん練習したことで自信がつき、「どんな感想をもらえるかな」「他の方の発表が楽しみ」、と緊張よりもワクワクが優りました。

5. zoomの画面共有の方法を確認

zoomはこれまでログインは何度もしたことはあるのですが、画面共有は1~2回しかしたことが無かったため、本番中に焦ってしまわないように、zoomにログインして共有方法を確認しました。

初めてLTしてみた感想

✅ オンラインの方が緊張しない

発表の順番がトリで、みなさんの発表内容もスライドも素敵だったので、直前は緊張しましたが、事前に練習していたため、トラブルなくスムーズに発表できました。
オンラインで初めてLTをした方の感想でよく、「聞いている人の反応が全く見えないので不安だった」というお話を聞きますが、私は逆に反応が見えないことで自分の発表に集中することができて良かったです。

カメラオフで発表させていただいたのもあり、発表している間自分の顔が相手から見えないため、オフラインと違って聞いている方とアイコンタクトをする必要がなく、原稿に集中できたことも、緊張度を下げてくれました。 私のような人の視線によって緊張するタイプの方は、オンラインでの発表が合っているかも、と思いました。

✅ 目標との間に小さい階段を作ると、実行へのハードルが下がる

私は大勢の前で発表することに緊張してしまう性格なのですが、LTに挑戦してみたいという思いがずっとありました。将来は技術に関するLTもやりたいと思っています。
しかし今回初めてLTをするまで、LTに対して「まだプログラミングを学び始めたばかりなのに技術について発表するのは自信がない...」「何十人もの人に対して発表するのは怖い...」「緊張してしまう性格なので、うまく発表できるか不安...」という精神的ハードルがありました。

そんな中今回のイベントは外部への告知はなく、TECHPLAY女子部の朝活チャンネル#hayaoki_girlsでクローズドに行われ、参加者が発表者含めて10人未満と少なかったこと、参加者全員が朝活等でお話したことがある方々だったことで、安心感があり、発表へのプレッシャーを下げてくださいました。

今回参加させていただいて、挑戦したいけれども勇気が出ないことを実行するには、目標との間に小さい階段を作ればいいんだ、と思いました。 知らない何十人もの人の前で技術に関する発表をするのはハードルが高いですが、まずはクローズドなコミュニティや顔見知りの少人数の前で発表したり、技術でないテーマで発表したりすること = 目標との間に小さい階段を作り、少しずつ登っていくことで、目標を達成できる、と思いました。

フィヨルドブートキャンプでも、「初心者が外部でLTをするのはハードルが高いので、まずはクローズドなコミュニティでやってみよう」と教えていただいていたのですが、今回実際に発表してみて、その意味が分かりました。 教えていただいて知っていることと、実際に実行して知ることは全然違うな、と感じています。
なにか挑戦したいことがあっても勇気がでない時には、このことを思い出して目標に向かって進もうと思います!

おわりに

今回、このような発表の場を設けてくださったTECHPLAY女子部の皆様、本当にありがとうございました。 今年もよろしくお願いします!

Rails Girls Gathering Japan に参加した感想

勉強会・イベント

はじめに

　この記事は、Rails Girls Japan Advent Calendar 2020の16日目の記事です。

　はじめまして。プログラマーを目指して、フィヨルドブートキャンプというプログラミングスクールで学習中のSakiと申します。
12/12(日)に開催された、Rails Girls Gathering Japanとというオンラインイベントに参加させていただきました。

Rails Girls とは

　Rails Girlsは、プログラミングを初めて学ぶ女性のサポートをしていらっしゃるコミュニティです。 詳しくはこちらのHPに載っています。

Rails Girls - Japanese

今回は初のオンラインイベントで、キーノートと一般公募によるLTが行われました。

LTの感想

　どの発表も素敵で本当に感動しました。 この感動が冷めないうちに記録しなくては！と思い、感想を書かせていただきました。

『As you Like It』emorimaさん

　なぜRailsGirlsをはじめとしたコミュニティ活動に力を入れていらっしゃるのか、お話してくださいました。 新しく一歩踏み出す人の不安に寄り添い、背中を押すお姿に感動しました。

また、「強さを追求するのではなく、自分らしくいられることが大事」というお言葉が心に響きました。 私自身、結婚や育児などのライフステージを迎えるまでに、早くキャリアを確立しておかなくては、という焦りがあったので、肩の荷がスッと下りた気持ちになりました。

『RailsGirlsに参加した13歳の少女のその後』三橋優希さん

speakerdeck.com

　RailsGirlsに参加されたことをきっかけに、RubyKaigiに参加されたり、技術同人誌を執筆されていたりと、行動力の高さに驚きました。
私の今年の学習を振り返ると、アウトプットすることに重きをおけていなかったので、来年は三橋さんのようにたくさんアウトプット・行動できるようにがんばりたい！と思いました。 また、心から楽しんでいる気持ちが伝わってきて、私も「プログラミングがとても楽しいから、仕事にしたい」という気持ちがあって学習しているので、とても励みになりました。

『デザイナがエンジニアの知識を持つこと』寺嶋章子さん

speakerdeck.com

　プログラマーとして就職したら、デザイナーの方とおそらく同じチームで働くことになるため、デザイナーさんの仕事内容や、「デザイナーがエンジニアの知識を持つとこういった面で役に立ったよ」というお話はとても勉強になりました。自分の仕事内容の領域だけを勉強するのではなく、他の領域を学ぶことも大切だということを学ばせていただきました。
また、発表を通して、仕事は一人でできるものではなく、様々な職種の方々が協力しあってできるものだということを忘れてはいけない、と思いました。

『RailsGirlsが私にくれたもの』harukusさん

speakerdeck.com

　「お金を払ってるだけではコミュニティに参加してるとはいえない」というお言葉が心に刺さりました。
私は、今年もっとコミュニティに積極的に参加すればよかった、という後悔があります。秋頃から、分からないことを質問したり、輪読会を始めたりするなど、コミュニティに参加し始めて、「勇気を出して一歩踏み出すと、みんな暖かく迎えてくださるし、一人ではできない濃い学びができるし、何よりも楽しい!」と感じ、行動したからこそ素敵な景色が見られることに気づけました。来年はもっとコミュニティに積極的に参加したいと思っているので、harukusさんがLTに挑戦されてる姿を見て、私もがんばろう！と勇気をいただきました。

『これ好き！から始める世界』べこさん

speakerdeck.com

　なにか新しいことを始めた時に、「お休みしても長期的に見たら続けているのと同じ、再開できれば続けているのと同じ」というお言葉が嬉しかったです。 私はフィヨルドに入会してから、ちょうど一年経つのですが、同じ時期に入会された方が卒業されていって、とても嬉しい反面、自分はまだ卒業まで遠いな、と落ち込むことがありました。
そういう時は、毎日少しずつでも勉強できていること、プログラミング学習をずっと変わらず楽しめていることに自信を持つように意識していたので、べこさんのお言葉が嬉しかったです。

　また、続けるコツは、「他人の言葉に振り回されないこと」と仰っていました。私もプログラミング学習を始めたばかりの頃、「プログラミングの何が楽しいの？」「プログラマーになんでなりたいの？」と聞かれてうまく答えられず、落ち込んだことがありました。
しかし、そういった言葉に振り回されて学習をやめることなく、「楽しい」という自分の気持ちに正直に学習を続ける中で、「こういうものが作れるようになりたい」「プログラミングでこういう問題を解決したい」「こんなプログラマーになりたい」といった考えが徐々に明確になりました。「新しいことを始める前から立派な理由・目標が無くてもいいんだ。」、と感じたので、他人の言葉は気にしなくていいというお話にとても共感しました。

『Rails Girls Effect 2012~』attsumiさん

speakerdeck.com

attsumiさんは、今年のRubyKaigiのデザインをなさった方です。

rubykaigi.org

rubykaigi.org

サイトがリリースされた時に、「とても可愛くて、素敵なデザイン!!」と思っていたので、まさかデザインをなさった方の発表をお聞きできると思っていませんでした。
attsumiさんは、デザイナーとして仕事をやっていけるかどうか悩んでいらしたところ、RailsGirlsに後押しされ、デザイナーになられたそうです。 私も、フィヨルドブートキャンプというコミュニティと出会っていなかったら、プログラミング学習を続けられていないと思うので、改めてRubyコミュニティって素敵だな、と思いました。

『エンジニア採用担当のRubyとの関わり方』福場麻美さん

speakerdeck.com

　自分の力でコードを書く中で分かったことの一つとして、「優秀なエンジニアと一緒に働けるという福利厚生を体感した」というお話が印象的でした。この福利厚生を得るために学習を頑張っているという面もあるので、とても励みになりました。

ご自分の職種の枠に囚われずプログラミングに挑戦していらっしゃり、楽しんでいる姿が伝わってきました。私は今はプログラマーを目指して学習中ですが、お話を聞いていて、自分の仕事領域に囚われずに関心を広げるようにしよう、と思いました。

『その後、ずっと幸せですという話』金子慶子さん

speakerdeck.com

　「プログラマーに転職したいけれど、口に出して否定されてしまったらどうしよう」というお気持ちに共感しました。 私もプログラマーを目指すことを、家族や知人に伝えるのに勇気が要りました。幸いにも伝えた人達はみんな「やりたいことが見つかってよかったね」と応援してくれましたが、肯定してくれたり応援してくれたりする人が周りに誰にもいなかったら、挑戦する前に諦めていたかもしれません。
なので、否定されるのは怖いけれど、勇気を出して伝えたら、応援してくれた！ということの嬉しさにとても共感しました。

『エンジニアが答えたくなる質問とは？』大倉雅史さん

speakerdeck.com

　質問で知りたいことはHowなので、5W1HのH以外を埋めれば自ずと分かりやすい質問になる、と教えてくださいました。 相手にとって分かりやすい質問をすることも学習中の身なので、次に質問するときはこの方法を実践しようと思います。
また、どのような職種・仕事でも相手にとって分かりやすい質問をすることは大事だと思うので、今の仕事でも5Wを埋めることを意識しようと思いました。

キーノート Akira Matsudaさん

キーボードを自作することを皮切りに、「自分に合ったものが無いなら、自分で作ろう・改善しよう」というお話をしてくださいました。

自分に合ったものがないから諦めるのではなく、自分で作ろう！改善していこう!という考え方がとても素敵だと思いました。 私もなにか問題に直面したときは、自分ができることないか？と考える癖をつけよう、と思いました。

さいごに

　みなさんの発表をお聞きして、私ももっと色んなことにチャレンジしたいと励みになりました！ 運営の皆様、発表者の皆様、すてきなイベントをありがとうございました。　

初めて輪読会をやってみたらいいことばかりだったので、良かったことをまとめました

勉強会・イベント 輪読会 オススメ!

この記事は、「フィヨルドブートキャンプ Part 1 Advent Calendar 2020」の6日目の記事です。

フィヨルドブートキャンプ Part 1 Advent Calendar 2020 - Adventar

昨日はFuushi−さんの バージョン管理ツール「Git」についてでした。

Part2もあります。

フィヨルドブートキャンプ Part 2 Advent Calendar 2020


目次

はじめに

　はじめまして。Sakiと申します。フィヨルドブートキャンプというプログラミングスクールで、プログラマーを目指して学習しています。

先日、「イラスト図解式 この一冊で全部わかるWeb技術の基本」(以下、Web技術の基本)という本の輪読会をして読了することができました。現在は「Webを支える技術 -HTTP、URI、HTML、そしてREST」(以下、Webを支える技術)の輪読会を行っています。

一人で読んだ時よりも良いことがたくさんあったので、輪読会をやって良かったことについて書きました。
この記事を読んで輪読会に興味を持ってくださる方が増えたら嬉しいです。

https://www.amazon.co.jp/%E3%82%A4%E3%83%A9%E3%82%B9%E3%83%88%E5%9B%B3%E8%A7%A3%E5%BC%8F-%E3%81%93%E3%81%AE%E4%B8%80%E5%86%8A%E3%81%A7%E5%85%A8%E9%83%A8%E3%82%8F%E3%81%8B%E3%82%8BWeb%E6%8A%80%E8%A1%93%E3%81%AE%E5%9F%BA%E6%9C%AC-%E5%B0%8F%E6%9E%97-%E6%81%AD%E5%B9%B3/dp/4797388811www.amazon.co.jp

TECH PLAY女子部さんに、輪読会の取り組みを取り上げていただきました。

techplay.jp

始めた経緯

　私の所属しているプログラミングスクールで、Webを支える技術を読むことが課題になっており、一人で読んだ時に知らない用語が多く、挫折してしまいました。この本が難しい場合はWeb技術の基本が、イラストが多く最初にイメージを掴むのに最適とアドバイスをいただいたので、一人で一通り読んでみました。

ちょうど読み終わった頃に、techplay女子部という女性エンジニアコミュニティで、Webを支える技術を一緒に読みませんか?と募集をしてる方がいらっしゃり、その方も分からない用語が多く読むのに苦戦されている様子だったので、Web技術の基本をおすすめし、一緒に輪読会を行うことになりました。

活動内容

  • 期間:10/7(水)~11/14(土)
  • 人数:２人
  • ツール:zoom / slack
  • 時間帯:毎朝5:00~6:00 (どちらか起きられなかったら無し)
  • 形式:予習なしで、その場で読む。10分で見開き1ページを各自で読み、次の10分で疑問点を共有する。これを3回繰り返して1時間。
  • 専用のslackチャンネル#book_webを支える技術があるので、参考になったURLや疑問点をそこで共有。

輪読会をやって良かったこと

一人で読んだ時と比べて、輪読は良いことがたくさんあったので、やって良かったことをまとめました。

✅ 疑問点をその場で気軽に共有できた

　文章の内容が理解できない際に、1人で読んでいた時は、分からない用語を調べて「きっとこんな感じかな」「こういう解釈でいいかな」という感じで、自己完結して先に読み進めていました。しかし、輪読会では疑問をその場ですぐに共有して調べあったり、話し合って整理したりすることができるので、高確率で答えにたどりつくことができました。
　その場で解決できなくても、slackのチャンネルに疑問点を投稿すると、そのチャンネルに入っていらっしゃる現役のエンジニアの方が現場の視点で教えてくださるので、疑問をそのまま放置することなく、読み進めることができました。

　また、一緒に輪読をした方が自分と同じ未経験からプログラマーへの転職を目指している方で、知識量や理解につまずくポイントが同じだったので、「こんなことも分からないの？と思われないだろうか」という不安がなく、疑問点をきちんと言語化できていなくても共有しやすかったです。

✅ 能動的に学習するので、理解が深まった

　様々な学習方法の中で、「人に教えることが一番高い効果を得られる」という話を聞いたことはないでしょうか？

ラーニング・ピラミッド
(平均学習定着率が向上する「ラーニングピラミッド」とは？より引用)

相手の疑問に答えたり、自分の解釈を話したりすることで、頭の中が整理されて理解が深まりました。
これは「人に教える」という学習方法を自然と行っていたからだと思います。

また、読んだその日のうちにscrapboxに学んだことをまとめたり、整理した疑問点をslackに投稿したりしていました。「せっかく輪読会をしたのに記録しないのはもったいない!」という思いがあったので、こういった作業も頑張ることができました。
以下は私がまとめたscrapboxの記事です。

scrapbox.io

✅ 技術・プログラミングの面白さを語り合える人ができた

私の周りにはプログラマーさんどころか、IT業界で働いている方もいないので、技術・プログラミングの面白さを語り合える人と出会うことができました。
この本はWebに関する技術について基礎から説明してくれるのですが、「この技術のおかげで今こんなに便利に使えているんだ！」「アイデアを形にできる力があるプログラマーさんってすごい！」という気持ちを共有できたのが本当に嬉しかったです。

✅ 運営側の楽しさを知った

　お互い輪読会が初めてで、どんな運営方法が良いか手探りで話し合いながら進めたので、会を運営する側も経験することができて、楽しかったです。
相手の方も「どんどん意見を出し合って良い時間にしましょう」と仰ってくださったので、色んな輪読スタイルを試せました。

具体的には、

  • 40分で見開き3Pを読んで、20分で疑問点を共有
  • 音読で代わりばんこに読んだ後、すぐに疑問点を共有

を行いました。
短く区切って読んだ方が話し合いをしやすい、理解につまずく場所が異なるので読む時は各自のペースにした方が良いという理由から、最終的に上述の形式にしました。

　また、スクールのメンターさんに、「せっかく輪読会をするなら、HackMD*1などのツールを使ってドキュメントをアウトプットすると良い」とアドバイスをいただいたので、今行っている輪読会で導入しました。

hackmd.io

リアルタイムで複数人でドキュメントを編集できるので、疑問点共有の時間を短縮できて効率的なので、使ってみてよかったです。

導入時も、「新しい方法に変えるのは面倒に思われてしまうかも...」と不安だったのですが、「そういう便利なツールはどんどん使っていきましょう！」と前向きに言ってくださったので、「もっとこの時間を良い時間にするためにはどうしたらいいか？」という提案を積極的にできました。

✅ コミュニティのありがたみを痛感した

　輪読会を進める中で、たくさんの方々に支援・応援していただきました。

Web技術の基本を読み終わったところで、techplay女子部の運営の方から、「少人数の輪読会をもっと広めたいので、インタビューさせてほしい」と仰っていただき、読了おめでとう会を開いていただきました。techplay女子部の方々には、本の疑問点に現場目線で答えていただいたり、読了のインタビューをしてくださったり、大変お世話になりました。

　また、途中で同じスクールの受講生の方から輪読会に参加したいと仰っていただけました(これも本当に嬉しかったです)。しかし、それまで無料のzoomを2人で使っており、3人で使うと一回40分までしか使えないという問題があるので、スクールのメンターさんに、スクールで契約しているzoomを使わせていただけないかとお願いさせていただきました。受講生でない方もいるので、「さすがに図々しかったかな...」と不安だったのですが、快く許可してくださり、なんとこの輪読会専用のURLまで発行していただきました。

　プログラミングの勉強を始めるまで、勉強というものは一人で黙々と進め、他者と競い合うものというイメージを持っていましたが、このような経験を通して、お互いに教え合い、協力し合うコミュニティのありがたさを改めて実感しました。助けてくださった方のご恩に報いるためにも、学習をがんばらねば、と思いました。 techplay女子部の皆様、フィヨルドブートキャンプの皆様、本当にありがとうございました。

おまけ:早起きを習慣化できた

　これはこの会にしか当てはまらないことですが、この会のおかげで早起きを習慣化できました。
元々相手の方が朝派で、私も早起きを習慣化したかったのと、お互いこの本を読み終わって早くWebを支える技術を読みたいという気持ちがあったので、毎朝5:00~6:00に開催しました。(今は6:00~7:00です)
techplay女子部の方が、「自分との約束は簡単に破れるけれど、人と約束すると起きられる」と仰っていて、その通りだと感じています。

さいごに

　輪読会をやって良かったことをまとめると、理解が深まることと、一緒に学習をがんばる仲間・応援してくださる方ができることです。 この記事を読んで輪読会に興味を持っていただけたら嬉しいです！

*1:Markdownで書いたドキュメントを複数人で編集でき、リアルタイムプレビューが可能なツール

【macOS】PostgreSQLのインストール&設定手順

データベース

PostgreSQLをmacOSにインストールし、起動・停止と新しくスーパーユーザーを追加してログイン設定までの手順をまとめた。

設定環境

インストール

HomebrewというmacOSのパッケージ管理システムを使ってインストール。

$ brew install postgresql

インストールできたか確認。

$ brew list # brewでインストールした一覧を確認できる
#=>postgresql があれば成功

起動・停止

インストールはできたが、このままではPostgreSQLを操作できないので、自動起動の設定にすることで使えるようにする。 自動起動とは、macOS を再起動した際にも PostgreSQL が自動で起動し、常に使える設定のこと。

PostgreSQLを自動起動。

$ brew services start postgresql

PostgreSQLを停止。

$ brew services stop postgresql

自動起動しているか停止しているかの、状態を確認。

$ brew services list
# => postgresql started # 起動している
# => postgresql stopped # 停止している

ログインし、新しくスーパーユーザーを作成

自動起動にしたら、ログインする。
インストールをした時に、macOSのユーザーが自動的にpostgreSQLのスーパーユーザーとして設定されているため、
初めてログインする際は、macOS のログインユーザーでログインする。

$ psql -U <macOSのユーザー名> postgres

このmacOSのユーザーとは別に、スーパーユーザーの権限を与えた操作用のユーザーを作る必要がある。

create user <ユーザー名> with SUPERUSER; # with SUPERUSER=スーパーユーザー権限を与える

※ なぜ新しくスーパーユーザーを追加する必要があるかは以下の記事の「なぜ新しくスーパーユーザーを追加するのか？」を参照。

saki-htr.hatenablog.com

作成したユーザーでログインできるか確認。

$ psql -U <ユーザー名>

以下の表示が出たら成功。

psql (12.4)
Type "help" for help.

postgres=#

次回からは、macOSユーザーではなく、新しく作成したスーパーユーザーでログインする。

参考記事

【Debian】PostgreSQLのインストール・設定・外部接続の手順

データベース

設定環境

Debianにインストール

macのターミナルを使っている場合は、Debianにリモート接続しておく。

Debianのバージョンを確認。

$ cat /etc/debian_version
#=>10.3

リポジトリのパスを記載するためのファイルを作成し、実行権限を追加。

$ sudo touch /etc/apt/sources.list.d/pgdg.list
$ sudo chmod u+x /etc/apt/sources.list.d/pgdg.list

リポジトリのパスを記載。

$ su
$ echo  deb http://apt.postgresql.org/pub/repos/apt/ buster-pgdg main  > /etc/apt/sources.list.d/pgdg.list

リポジトリのパスが記載されたか確認。

$ cat /etc/apt/sources.list.d/pgdg.list
#=>deb http://apt.postgresql.org/pub/repos/apt/ buster-pgdg main

CA証明書をインストール。

$ sudo apt install wget ca-certificates

PostgreSQL公開鍵(リポジトリ署名キー)を追加。

$ su
$ wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | apt-key add -
$ exit

パッケージリストの更新

$ sudo apt-get update

インストール。 この時バージョンを指定しなければ、最新バージョンをインストールする。

# 最新バージョンのインストール
$ sudo apt-get -y install postgresql
# 特定のバージョンのインストール
$ sudo apt-get install postgresql-<バージョン番号>

インストールできたか確認。

$ psql --version 
# => psql (PostgreSQL) 13.0 (Debian 13.0-1.pgdg100+1)

インストールはこれで完了。

PostgreSQLにログインして設定を行う

PostgreSQLをインストールすると、自動的にpostgresという、データベースの管理ユーザーが作成されるので、このユーザーでログインする。

$ sudo su - postgres

新しくスーパーユーザーを追加する。

$ createuser --pwprompt --interactive <ユーザー名>

上記を入力すると、設定したいパスワードと、スーパーユーザーにするかを聞かれる。 パスワードを2回入力し、yを押してスーパーユーザーとして設定する。

Enter password for new role: 
Enter it again: 
Shall the new role be a superuser? (y/n)

今作ったユーザーでログインする。

psql -U <ユーザー名> -d postgres -h localhost

プロンプトが以下に変われば成功

postgres=#

ちなみに、ユーザー一覧は\duで見ることができる。

なぜ新しくスーパーユーザーを追加するのか？

postgresユーザーをそのまま使わず、新しくスーパーユーザーを作成する理由が分からなかったので、調べた。
公式ドキュメントの21.2. ロールの属性によれば、

スーパーユーザー以外にCREATEDB権限とCREATEROLE権限を持つロールを作成することを勧めます。 そして、このロールを使用して、データベースとロールを管理するためのすべての処理を行ってください。 この方法によって、実際には不要な処理をスーパーユーザーとして行う危険性を避けることができます。 とある。

※ロール=ユーザーのこと。

つまり、postgresユーザーは権限の範囲が広い=何でもできてしまい、普段ログインして使うには危ないため、新しくスーパーユーザー権限を与えたユーザーを作成して使う必要がある。

外部接続の設定

外部接続とは、自分のmacから、PostgreSQLを使ってサーバーのデータベースに接続すること。 以下の手順はすべてDebianにリモート接続した状態で行っている。

PostgreSQLの設定が記述されている、postgresql.confを編集する。 ここで、バージョン番号を間違えると、「そのようなファイルはありません」とエラーが出るので注意。

$ sudo vim /etc/postgresql/<バージョン番号>/main/postgresql.conf

ファイルの60行目あたりの、# - Connection Settings -に、

listen_addresses = 'localhost'

とあるので、これを

listen_addresses = '*'

ここで、#を消さないと設定が反映されないので注意。

自分のIPアドレスを確認。 $ hostname -I

次に、 pg_hba.confファイルを編集する。

$ sudo vim etc/postgresql/13/main/pg_hba.conf

認証を受け付けるIPの範囲を追記する。 変更ではなく、追記な点に注意。

# IPv4 local connections:
host    all             all             <自分のmacのIPアドレス>/32         md5

再起動。

$ sudo service postgresql start

これで外部接続の設定は完了したので、できるか以下のコマンドで試す。

$ psql -U <postgresqlのスーパーユーザ名> -d postgres -h <ホスト名>`

postgres=#と出たら成功。

参考記事