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

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

週報 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=#と出たら成功。

参考記事

「新しいLinuxの教科書」を読む会 オンライン #2 参加レポート

Linux 勉強会・イベント

はじめに

こんにちは。紗希と申します。 プログラマーを目指して、フィヨルドブートキャンプというプログラミングスクールで学習をしています。
先週の6月20日(土)に、著者である三宅さんと大角さんによる、「新しいLinuxの教科書」のオンライン読書会#2 に参加させていただきました。 お二人がそれぞれLTをしてくださり、資料をコンパスのページに載せてくださっています。 その中で学ばせていただいたことや感想をまとめさせていただきました。

linuxbook.connpass.com

✅ lsコマンドは-Fオプションが便利なので、エイリアスを設定するのがオススメ

-Fオプションをつけると、それぞれのファイルがひと目でファイルかディレクトリか判別できる。 例えば、ディレクトリには後ろに/が付く。エイリアスを設定して、lsを入力するとls -Fが実行されるようにすると便利。 以下は私のホームディレクトリでls -Fコマンドを入力した例。 f:id:Saki-Htr:20200625074347p:plain

✅ なぜディレクトリ名に日本語を使ってはいけないのか

本では、「日本語のディレクトリは、文字化けなどさまざまな問題が発生するおそれがあるため、利用しないことをお勧めします。」(三宅 英明,大角 祐介. 新しいLinuxの教科書 (Japanese Edition) (Kindle の位置No.1666-1667). Kindle 版.より)とある。
これに関して三宅さんと大角さんは、「今は文字化けすることは無いと思う。しかし、圧縮・展開する時に文字化けすることがあり、そもそも日本語名のディレクトリにすると入力する時に面倒である」と仰った。
たしかに、通常Linuxを使う時は半角英数字で使うので、わざわざひらがな入力の設定にして日本語を入力するのは面倒だと思った。

実際にmkdirで日本語のディレクトリを作ったが、文字化けしなかった。しかし、日本語名を使うことで余計な問題が発生する可能性があるのなら、使わない方がいいと思ったので、使わないことにした。

✅ rmコマンドは本当に簡単に消えるから気をつける

  • rmコマンドは-iオプションをつけないと「本当に消していいですか？」と聞いてくることも無いし、バックアップをとってくれることも無いし、ゴミ箱機能もない。本当に跡形もなく消える。
  • 以下、とくに気をつけるべきコマンド
#入力ミス(例:ファイル拡張子が.txtのファイルを全消去したい時)
$ rm *.txt  #これが正解
$ rm * .txt #*と.txtの間にスペースがあると、*と.txtの両方が全消去される😱

#絶対うってはいけないコマンド
$ rm -rf -no-preserve-root #全部消去😱
#rmのコマンドが/usr/bin/rmからメモリに読み込まれ、最後まで実行されてしまう

$ rm -rf / #ファイルシステム上のファイルを全消去する(今は実行できない)→システムは機能しなくなる😱

#上記のオプション解説
-r:ディレクトリごと削除
-f:強制的に全消去

✅ シンボリックリンクはバックアップをとる時に注意

  • バックアップをとるためにcpコマンドを使う時に、間違えてシンボリックリンクをコピーしていて、元の実体ファイルをコピーできていないことがあるので、注意。

✅ ハードリンクは現場ではほぼ使われていない

  • lnコマンドを使ってリンク作成することができる。リンクには2種類あり、オプション無しでハードリンク、-sオプションを付けるとシンボリックリンクが作成できる。
  • 昔はハードリンクしかなかったため使われていたが、今はシンボリックリンクの方が便利なので、能動的に使われることはない。
    • 「今この世にあるハードリンクは-sオプションをつけ忘れて、間違えて作られたハードリンクが一番多い」という話も😂
  • では、なぜハードリンクを学習する必要があるのか?

→ -sオプションをつけ忘れて間違えてハードリンクを作ってしまうことがあるので、その時ハードリンクがなにかを分かっていないと困るため。

✅ ファイル検索するfindコマンドとlocateコマンドの使い分け

  • ファイルを検索するコマンドは2つあり、findコマンドとlocateコマンドがある。
  • それぞれ特性があり、メリット・デメリットがある。以下は、私がまとめた違い。 f:id:Saki-Htr:20200625080727p:plain
  • これを踏まえ、お二人に以下の質問をさせていただいた。
findコマンドとlocateコマンドはそれぞれメリット・デメリットがあるかと思いますが、
お二人は実務でどのように使い分けていらっしゃるかお聞きしたいです。

✍🏻 三宅さんのご回答

  • findしか使わない。findだけでもそんなに困らない。
  • 昔はすごく時間がかかったが、今はfindも早くなってきている。 どれくらい早くなったかというと、検索に1hかかっていたものが今は20秒で検索できる程の早さ。
  • findの方が細かい条件指定ができる点は大きい。(書き方が細かいが)

✍🏻大角さんのご回答

  • findはフォーマル、locateはカジュアル
  • 「ファイルを探して、何かを実行する」プログラムを書く時=プログラムにかませる時にfindを使う。
    絶対にそのファイルが存在していることが分かっている時に使う。
  • 障害があってシステム報告書を書く時、エビデンスのためにfindを使う。
  • locateはフランクに使えるコマンド。

➡人によって使い分け方が違うので、自分にとって最適な方法を模索していきたい。

✅ 使い方がわからない時はまず、一次情報に触れる

  • Linuxにはコマンドの使い方などが載っている、manや--helpがある。 検索してQiitaなどのネット記事を見たくなる気持ちは分かるが、まずmanを見よう。
  • ワンランク上のエンジニアになるには、この癖をつける。
  • Linuxのマニュアルの和訳サイトがある:JM Project
    ターミナルの狭い画面よりブラウザの方が見やすい。
  • ただコピペするのでなく、そのコマンドの意味も調べる
  • なぜ最初にネット検索してはいけないのか
    • Qiitaなどのブログ記事は、書いた人の勘違いなどがある可能性がある。
    • Qiita自体が悪いといっているわけではなく、一次情報を読む前にネット検索することが良くないということ

✅ infoコマンドはすごく難しく、初心者向けではない

  • 本に載せなくてよかったとのこと...(笑)
    なぜなら、初心者向けでなくすごく難しいから。
  • 難しすぎて、info infoと入力するとinfoを読むためのチュートリアルが出てくる。ヘルプのためのヘルプ!(笑)
  • しかし、より最新の情報が反映されているので、見ても無駄ということはない。

✅ 三宅さんのLT:『READMEを書こう』

  • READMEとは：アプリケーションの使い方や注意を書いた文章。自分がリリースする時の準備。
  • ちゃんとしたものを書くと、インストールするか迷っている人が、「この開発者はしっかりしてる」と思い、使う気になる
  • 誰に向けて書いているか:まだ使い始めていない人、使い始めた人、自分も結構忘れるので自分にも。
    • インストールした人に向けて書くものだと思っていたので、使うかどうか迷っている人の判断基準の一つになるという点は意外だった
  • 本体の実装前に書くのがおすすめ
  • 理由①実装している時が盛り上がりのピークで、完成したらやる気がなくなってしまうため。
    • "やる気"という観点が面白いと思った。
  • 理由②実装し終わってる頃にはすごく詳しくなっていてユーザー目線で書けなくなっているため。 だんだん詳しくなると、前提知識が違うから使うか検討している人、これから使う人の目線に立って書けなくなってしまう。 でも実装前だとユーザーと同じ気持ちで書ける。
  • なので、✕こういう風に作りました→◎こういう風になってほしい、こういう使い方をしたい、というユーザー目線で仕様を決めて書く
    →そうやって仕様を決めると使いやすくなる。
    • READMEを書くことで、何のために作るのか、どんなものを作るのか、どんな実装をするのか頭の整理をすることができるのは大きいと思った。
  • はじめのうちは他の人が作ったツールを参考にするのがよい。なので、世の中にあるアプリケーションやツールを使ってみることが大事。

✅ 大角さんのLT:『/proc を見てみる』

  • /procとは?これもman procでマニュアルが出てくる →これによれば、procとはプロセスの情報を含む擬似ファイルシステム
  • プロセスとは→本のチャプター10に説明が載っていた
  • この/procファイルを通して、カーネルの現在のプロセス管理状態や各種情報の取得を行う。 一部は書き込み=設定変更 も可能。
  • これを使ってわざとシステムをクラッシュさせることもできる

✅ チーム開発で気をつけていること

以下を質問させていただいた。

前回の勉強会で大角さんは、表示内容を全消去するclearコマンドをペアプロで使うと、
相手に無駄に余計に考えさせてしまうので使わないと仰っていましたが、
他にチームで仕事をする時に気をつけていることがございましたら、
教えていただきたいです。

✍🏻 大角さんのご回答

  • 相手の脳のメモリを無駄に消費させないように心がけている。
  • 例として、「GitHubでlgtmという文化があるが、これには反対」というお話をしてくださった。

◎ lgtmの問題点

例えば、 GitHubを使ってAさんとBさんで一つのシステム開発をしているとする
↓
Aがコードを修正して、プルリクエストを送る
↓
Bがレビューする。このレビューする時に「lgtm」とコメントするのが最近流行している。
lgtmとは:"Looks Good To Me”=「自分的にはOKだよ」という意味。
開発したシステムやコードのレビューをお願いされた時に使う。

◎ lgtmと返すことの何が問題なのか？

  • この後別の開発者Cさんが入ってくるかもしれない。
    AさんBさん同士はなぜそのプルリクエストが採用されたか分かっていても、Cさんにはなぜそのレビューを通したのか、lgtmでは分からない。
  • とくにトリッキーなコードは良くない。
  • またペアプロでは、当人同士で話して完結して満足して終わりになってはいけない。

◎ 大角さんがレビューする時に書くこと

1. 「私は○○をチェックした」 =自分はどこをチェックしたか
2. 「✗✗機能はちゃんと動いていた」
3. 「△△はちょっと変な書き方に見えるけど、まあ細かすぎるので良いでしょう」
  • 多くの人は3まで書かない。
  • しかし、今後このプログラムがどのように使われるのか分からないので、できる限り細かく書く。
  • 結論=人の頭の中を過剰にテキストにする

✅ 感想

✍🏻大角さんの「チーム開発で気をつけていること」に対するご回答について

  • 質問したらとても深いご回答をいただけて、「lgtmだけをコメントしないで細かくレビューすべき」というお話は、私も実務に入ったら心がけようと思った。(もちろんスクールのカリキュラムでも!)
  • また、このお話もためにGitHubとはそもそも何か、lgtmとはそもそも何かまで丁寧に説明してくださった。
  • 「相手の脳のメモリを無駄に消費させない」という点は、どのお仕事でも当てはまることで、私も仕事で意識していることでもあったので、とても共感した。
  • まだGitHub等を使ってチーム開発をしたことはないが、"lgtmとしか書いてなかった場合に起こりうる無駄"を考えてみた。
    • 後から入ってきた人が、なんでだろう？と考える時間が無駄である
    • 理由をレビューした人に聞く時間が無駄である。
    • しかもその人が覚えていたらいいけど、前に書いていたら覚えていない可能性もある...
    • レビューした人が退職していたら、採用した理由はもう分からない...
  • 細かくレビューを書くことは、その瞬間のその人の時間だけを考えると、その人にとっては面倒かもしれない。
    しかし、チーム全体の「時間」と「人に無駄に考えさせることを減らす」という観点から私も考えてみたところ、「細かくレビューするべき」と思った。

    ✍🏻復習することの大切さを知る

  • この本を初めて読ませていただいたのは今年の1~2月なのだが、今回復習をしたら、理解が十分にできている所と理解が曖昧な所が浮き彫りになった。
  • 中には、毎回同じ箇所でつまずく度になんとなくで先に進めている所もある。
  • なので、今回理解が曖昧な所は復習してきちんと理解して次に進もうと思った。そしてそれをブログでアウトプット！

✍🏻勉強会参加にあたっての準備の大切さを知る

  • 勉強会の前にその単元を予習してから参加にのぞむことの大切さを実感した。
    その方が勉強会の時間を有意義にできると、頭では分かっていても、なかなかサボって行動にできていなかった。
  • 実務で既にバリバリLinuxを使っているならまだしも、勉強の時にしか触っていない＆オプションもそんなに使いこなせていない＆教科書の内容の細かい部分は頭から消えてしまっている状態では、せっかく良い話をしてくださっても、前提知識にとても差があるので意味が理解できない。
    例えば、findコマンドとlocateコマンドの使い分け方について質問させていただいたが、そもそも私が2つのコマンドの違いを把握していないと、せっかく実務ではこう使っていると話してくださっても理解できなかった。

✍🏻 質問を用意して参加した

  • 質問を2つ用意していて、チャットにコピペする用のメッセージも用意していたが、オンラインで何十人もいる中で送るのはとても緊張した。 一瞬諦めようかと思ったが、復習･準備した意味がなくなってしまうので、質問したら、とても丁寧にご回答いただけたので、勇気を出してよかったと思った。 おそらくオフラインよりもオンラインのほうが質問することのハードルは低いので、どんどん質問して慣れていきたい。

さいごに

著者のお二人が「本の内容と関係ない質問でも大丈夫ですよ」と仰ってくださり、とても質問しやすい雰囲気でした。

「このコマンドはこのオプションを使うと便利」という使い方のお話、「本ではこう書いたけど現状はこうなっている」という最新の情報など、たくさんお聞きすることができました。

また開催されましたら、ぜひ参加したいです。 三宅さん、大角さん、大変貴重な機会をくださり、誠にありがとうございました！