Bubble Bath

野球が好きすぎる女子インフラエンジニアのBlog

#everyoneoutputer ができるまで

この記事は Everyone Outputer Advent Calendar 1日目の記事です。

adventar.org

記念すべき #everyoneoutputer 初のアドベントカレンダー1日目は、「このコミュニティができるまで」について書きます。

野球の話はまたの機会に

ことのはじまり

Everyone Outputerとは、技術書典5で頒布された「セイチョウ・ジャーニー」という本の第3章「マヨイ・ジャーニー」に登場する架空のコミュニティ。

……だったはずでした。

え?セイチョウ・ジャーニーって何ですか、って?

そんなあなたはこちらへ!!

booth.pm

完全なる発端

技術書典5終了後、「マヨイ・ジャーニー」著者であるVTRyoさんがなんと 架空のコミュニティを現実世界にデプロイ します。

everyone-outputer.connpass.com

名乗りをあげる

ちょうどその頃、アウトプットの幅を広げたかったわたしは名乗りをあげます。

捕捉される人々

Aizackさん

一瞬にしてVTRyoさんに捕捉され、主催に加入。 すごいなTwitterの世界。

くろたろうさん

twitter.com

わたしとほぼ同時期にSIerからWeb系に転職し、しがないライフを満喫されている方を釣りました。快諾ありがとうございまーす!

イベント開催

主催メンバーで議論した結果、今年のうちにイベントを1つやる、という方向で進みました。

準備!準備!

転職LT主催であるVTRyoさん以外は、初めてのイベント主催。 Aizackさんに至ってはそれに初LTも加わります。

なにもわからない状態ですがやることは山積み。

  • 会場確保、人数決定
  • タイムスケジュール
  • 懇親会
  • その他もろもろ

イベントページ公開

10/22にイベントページを公開。(主催メンバーで酒を飲みながら)

everyone-outputer.connpass.com

直前の転職LT#3にて、「夜中に公開と同時に募集開始したら朝にはほぼ埋まっている」事態が発生したため、10/24の12:00を募集開始に定めました。

そしたらなんと……

LT枠が開始1分で瞬殺

あわな→( ゚д゚)ポカーン

発表者のおひとり、hekitterさんに至っては11:59に職場のトイレで待機していたそうです…

予想以上の反響でした。 あとから1枠LT増やしました。 今回LTできなかった皆様、申し訳ありません…。次回以降お願いいたします!

いよいよ当日

準備をあれこれしているとあっという間に当日。

緊張の面持ちで迎えました。

みんなちゃんと来てくれるだろうか...?

結果、そんな心配は杞憂に終わり、イベントは盛り上がりました!よかった! 自分の主催したイベントで反響があるのエモいですね。泣きそうになる。

至らなかったところも多かったですが、参加してくださったみなさま、ありがとうございました!!

反響

参加された方がレポートしてくださっています。

へきったーさん

note.mu

しんくうさん

shinkufencer.hateblo.jp

みずりゅさん

mzryuka.hatenablog.jp

ゆめちさん

namonakimichi.hatenablog.com

FORTEさん

fortegp05.hatenablog.com

@長岡さん

ih6109.hatenablog.com

kabukawaさん

kabukawa.hatenablog.jp

てぃーびーさん

tbpgr.hatenablog.com

今後の予定

Everyone Outputer、まさかイベントを1回やっただけで終わるわけにはいきませんよ?

次回イベント

2019年初旬に次回イベントを予定しています!!

そのほか

イベント以外の活動も予定しています。乞うご期待!

明日のアドベントカレンダーは主催のひとり、Aizackさんです!

twitter.com

AWS AMIの共有→コピーでハマった話。

検証環境でEC2の構築が終わったので、AMIにして本番環境にもっていきたい。

このように、アカウント間でAMIを共有し、共有先でAMIをコピーしたいとき。

簡単にできるものだと思っていましたが、意外とハマってしまったので、その方法を説明します。

https://4.bp.blogspot.com/-YhtXKhx5-CM/WR_KiDM7kmI/AAAAAAABEXM/GXAsRRoRJl0ztmis7bt2lQy183zfb4stwCLcB/s400/business_jouhou_koukan.png

間違った方法

⚠️わたしは普通にこうやってハマりました

共有させたいAMIを選んで「アクション」→「イメージパーミッションの変更」

f:id:awana1023:20181122162935p:plain

共有先のアカウントIDを入力して「アクセス許可の追加」→「保存」

共有先のアカウントに移動し、AMI検索窓の左の「自己所有」をクリックして「プライベートイメージ」を選択

共有したAMIが表示されるので選択して「AMIのコピー」 リージョン選択していざコピーしようとすると f:id:awana1023:20181122164550p:plain こんなエラーが出ます。

アクセス許可はつけたはずなのに...?

原因

AMIと紐づくEBSボリュームへのアクセス権がない

アクセス許可はAMI自体だけではなく、EBSボリュームにも与えないといけないわけです...!

正しい方法

共有設定時に、

パーミッションを作成するときは次の関連付けられたスナップショットに "ボリューム作成" パーミッションを追加する:」

にチェックを入れる。

(一度失敗して共有設定をやり直す場合、いったん設定を消してからやりなおしてください)

もしくは

表示されているスナップショットのIDをスナップショット一覧から検索し、そちらに「権限の変更」から共有設定をする。

このいずれかを行うと、共有先でAMIのコピーが可能になります!

簡単なことのはずですが、意外と落とし穴になっている気がします。(実際わたしはこれで半日潰した)

おすすめAWS参考書

現在AWSを仕事で使っていて学習中なので、読んでいる参考書を紹介します。 AWSを広く浅く理解するにはうってつけの参考書だと思います。

Amazon Web Services実践入門 (WEB+DB PRESS plus)

Amazon Web Services実践入門 (WEB+DB PRESS plus)

GitHubことはじめ〜はじめてのプルリクエスト〜

こちらの記事の続きです。

awana1023.hatenablog.com

いよいよ、はじめてのプルリクにたどりつくまでの操作を行っていきます!

大まかな手順はこちら。

f:id:awana1023:20181116013803p:plain

1. リポジトリ作成

リポジトリとは、貯蔵庫のことです。 ここにソースコードなどを貯めていきます。

「New Repository」をクリックし、新規作成を行います。

f:id:awana1023:20181116002941p:plain

Repository Nameを設定します。 また、「Initialize this repository with a README」にチェックを入れておきます。 こうすることで、リポジトリのトップ画面にREADMEを設定できます。

公開範囲は、無料版の場合「Public(全世界に公開)」のみです。

有料版の場合は「Private(非公開)」も利用できます。

f:id:awana1023:20181116003441p:plain

「Create Repository」をクリックすると、以下のような画面になります。 これで自分のリポジトリが作成できました!

f:id:awana1023:20181116003530p:plain

2. リポジトリをフォークし、クローンする

フォークする

フォークは、共同開発など、編集対象のリポジトリが自分のものではない場合のみ行います。

リポジトリ右上の「fork」ボタンをクリックすると、 「自分のアカウント名/フォークしたリポジトリ名」というリポジトリが作成されます。

クローンする

クローンは個人開発でも共同開発でも行います。

ブラウザ上で「Clone or Download」をクリックします。 もし「Clone with HTTPS」が表示されている場合は、「Use SSH」をクリックします。

URLの右にあるクリップボードを押すと、URLがコピーされます。

ここからはターミナルでの作業になります。

以下のコマンドをターミナルで打ちます。

$ git clone 「コピーしてきたURL」

$ git clone git@github.com:awn-km23/test-repository.git

クローンが成功すると、cd [リポジトリ名]というコマンドが打てます。

$ cd test-repository

3. ローカルで編集する

各自好きなようにor必要に応じてファイルを編集します。 今回は、新規にhelloworld.rb というファイルを作成したとして進めていきます。

4. ブランチを切る

ブランチとは直訳すると「枝」です。メインのリポジトリに直接影響を及ぼさないよう、自分用の並行世界を作ります。

ちなみに、メインの枝にはmasterブランチという名前がついています。

ブランチを作成し、そのブランチをチェックアウトすると、並行世界に入ることができます。

例. rubyという名前のブランチ作成、そのブランチに移動する

$ git checkout -b ruby

5. 作成や変更を反映させる

$ git add helloworld.rb

このコマンドで、ファイルやディレクトリの作成・変更をインデックスに反映させることができます。

インデックス:コミットする前に、変更した内容を一時保存する場所

もし変更をかけたすべてのものをインデックスに反映させたい場合は以下のコマンドとなります。

$ git add .

ただしこのコマンドを使うときは、Gitでの管理対象としないファイルを指定する.gitignore を作成した後にすることをおすすめします。 gitignoreについてはこちら。

www-creators.com

6. コミットする

コミットする先はローカルリポジトリです。結果ではありません

コミット:ファイルやディレクトリの追加や変更をリポジトリに記録する操作

以下のコマンドで行います。

$ git commit

実行すると、コミットにメッセージを記載することを求められます。 自分がどんな変更をしたかわかるように、書いておきましょう。

7. リモートリポジトリにプッシュする

$ git push origin ruby

ローカルリポジトリにかかった変更を、GitHub上のリモートリポジトリに反映させます。 originの後は自分が現在チェックアウトしているブランチ名を入れてください。

8. プルリクエスト作成!

プッシュを終えてGitHubのブラウザ画面に行くと、リポジトリにこんなものが表示されています。

f:id:awana1023:20181116012502p:plain

「Compare & Pull Request」をクリックします。

f:id:awana1023:20181116012647p:plain

タイトルとコメントを記入し、「Create Pull Request」をクリックします。

これにて、プルリクエストが作成されました!

9. プルリクエストを受けてマージする

「Merge Pull Request」をクリックすると、masterブランチに今までの変更が反映されます。

複数人で開発を実施している場合は、この前に他の人からコードのレビューを受けたり、確認してもらったりしてください。 レビューを担当した方が「この変更でOK!」と確認できたら、「approve」を送ってくれるはずです。

approveの直訳:認める、賛成する

approveをもらえたらマージしましょう。

これにて一通りのGitHub操作は完了です!

おわりに

GitHubを初めて本格的に触ったころは、次々現れるカタカナに苦戦した覚えがあります。

しかしそれから1週間も経たずに、一連の流れはマスターでき、今ではすぐにプルリクエストを作れるまでになりました。 (ただしコードの出来は...聞かないでください)

本当に初心者!という方はこの本をおすすめします。 GitとGitHubについて、非常にわかりやすく解説されています。わたしも読みました。

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

それでは、たのしいGitHubライフを!

転職LT#3で人生初LTしてきた話。LT準備から本番まで。#jobchanger

11/7に開催された転職LT#3にて、人生初のLTをしてきました。

ex-sier.connpass.com

https://3.bp.blogspot.com/-Ur4Zt1qoCQA/WMo8-RRujxI/AAAAAAABCpI/5ZtpNwjoZyMGith2R_DN-nV8rzCKQpvXgCLcB/s400/presentation_pc_woman2.png

大事なこと

LT準備、本当に大事。

LT準備の成果が当日のLTの出来を左右すると言っても過言ではないです。

LTすることになったきっかけ

きっかけは、前回の転職LT直後の自分のツイートでした。 前回の転職LTには参加できなかったのですが、その直前にちょっと話してみたい的なツイートをしたところ... 主催者であるVTRyoさんからリプが!

お声掛けいただき、事前立候補枠としてLTすることとなったわけです。

最初参加者60人って聞いてたのに増枠で100人になっててびっくり。

さて何を話そう

今年の8月に転職したので、その経験談を話すことは決めていました。

が、どの軸で話すかが決まらない。

というかLT初めてだし、LTの現場に参加したこともないし、勝手がわからない…

そこで勉強会に参加して実際のLTを聞いたり、「LTの準備の仕方」みたいなページを見て参考にしたりしました。

参加したのはJAWS-UG初心者支部です。

jawsug-bgnr.connpass.com

準備には主にこのQiitaページを参考にしたりしました。

qiita.com

いよいよLTの準備をする

準備大事!(2度目)

話す内容を整理する

まず何を話すか、紙に書き出していきました。 ここは紙でもPCでもスマホでもいいと思います。

わたしの場合は転職体験談を話すと決めていたため、

  • 転職前の話
  • 転職活動の話
  • 転職後の話

とおおまかに分け、話すことを決めていきました。

ここで大事なのは、とにかく書き出すこと。 これ話すのは微妙かな?と思っても書き出してみてください。 ネタをたくさん出した方が、後ほどのスライド作成がやりやすくなります。

そしてスライドを作る

話すことが決まったら、いよいよスライド作成です。

今回、初めてKeynoteAzusa Colorsを使いました。 理由はなんかLTっぽかったからです。他意はありません。 もちろんPowerPointでもGoogleスライドでも全然ありです。

更に大体いい感じになるkeynoteテンプレート「Azusa Colors」作った - MEMOGRAPHIX

今回気をつけたのは以下です。

  • 文字は大きく
  • スライドが寂しくならないよう、時々画像も使う
  • 1個ぐらいネタも入れたい
  • スライドに話すすべての内容を書かない(LTがスライドの読み上げにならないようにする)

練習する

せっかくスライドができても、持ち時間内におさめなければ意味がありません。

スライドの大枠が仕上がってから、家でぶつぶつとしゃべりながら練習していました。

コンテンツごとに時間を区切り、それに収まるようスライドの分量を調整していきます。 10分におさまらず、思い切ってスライドからカットした部分もありました。

レビューをもらう

Slackの「エンジニアの登壇を応援する会」にて、スライドのレビューを受けました。

そこで

  • スライドのマナー
  • コンテンツごとの分量の配分

などを指摘していただき、スライドに修正をいれました。

反省点は、レビューに出したのが直前すぎたことです。 次回のLTのときはもっと早く出す…!

ちなみに「エンジニアの登壇を応援する会」はこちらです

エンジニアの登壇を応援する忘年LT大会|IT勉強会ならTECH PLAY[テックプレイ]

忘年LT大会、わたしも登壇予定です!(ここぞとばかりに宣伝)

レビューはあったほうがいいです。 誰かいればお願いしてみましょう。 いなければ...エンジニアの登壇を応援する会へ!(また宣伝)

そしていよいよ当日

出番がやってくる

吐きそうなぐらい緊張していました。 Twitterでは「吐きそう」しか言っていなかった記憶があります。

ほらやっぱり。

会場に着き、接続確認を済ませます。

会場はこちら、株式会社プレイド様。

株式会社プレイド | データによって人の価値を最大化する

自分の番がくるまで緊張しながら待ちます。 自分より前のLTの記憶が全然ないぞ...

自分の番がきました

手も足もめちゃくちゃ震えていました。(実話)

こんなの初めてです。

でも1度始まってしまえばあとは終わりまで突っ切るのみ、 いつの間にか震えも消えていました。 ド緊張するのは最初だけと学びました。

発表を終えて拍手をいただくときがいちばん爽快でした!!!

懇親会

終わった後は懇親会! 今回、株式会社Carat様と株式会社DIVE INTO CODE様が飲食スポンサーとして協賛されており、 かなり豪華な寿司とピザをいただけました。すごい。

スポンサー様2社はこちらから。

株式会社Carat | すべての人をより輝かせる

DIVE INTO CODE | プログラミングスクール

懇親会で「LT良かったです!」「私も転職したいんです!」などと声をかけていただき、いろいろな方と仲良くなれました。 嬉しかったです。

発表資料

当日の資料はこちらです。

おわりに

今回初めてLTしてみて思ったのはこの3つ。

  • アウトプット大事だと感じた
  • またLTやってみたくなった
  • LTは準備が超大事(3回目)

LTすると、人前で話すことに慣れていけそうです。 今年はもうあと1~2回LTする予定です。 あれ?ハマっちゃってる??

GitHubことはじめ〜コマンドでGitHubを操作できるようにする方法〜

  • GitHubを会社で使うことになったけど、やり方がわからない!
  • コマンドでGitを操作したいけど…なんだか難しい!

そんな駆け出しエンジニア、きっとどこにでもいると思います。 もしくは、Web系エンジニアになりたい!と思ってアウトプット活動をはじめたけれど、 GitHubの使い方で詰まっている方。

実際、わたしがそうでした。 仕事でGitHubを使うことになりましたが、用語も設定方法もわからず、 なにそれおいしいの?状態でした。

そんな方々のために、

コマンドでGit、GitHubを使えるようにする設定 を解説します!



目次



想定環境

  • MacOS
  • 会社やチームなどでGitHubを使うことになった
  • コマンドでのGit操作をしたい

https://blog-plaid.com/wp-content/uploads/2018/03/github-logo-1000x333.png



ターミナルでGitを使えるようにする

Gitがインストールされているか確認

Macの場合、はじめからGitがインストールされています。 以下のコマンドをターミナルで叩いてみてください。

$ git --version
git version 2.15.2 (Apple Git-101.1)

git version x.x.x という結果が返ってきたら、すでにあなたのPCにはGitがインストールされています。

めでたしめでたし。

エラーが出てしまったら

MacOS Mojave/High Sierraなどで、以下のようなエラーが出てしまうことがあります。

$ git --version
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

これはソフトウェアアップデートにより、コマンドラインツールが吹っ飛んでしまっているために起こります。 そんなときはこのコマンドを叩いてみてください。

$ xcode-select --install

インストーラが立ち上がり、無事Gitコマンドを使えるようになります。

GitHubのアカウントを取得する

まずはここから

https://github.com/

上記のサイトに飛びます。 もしアカウントを持っていなければ、

  • ユーザ名
  • Eメールアドレス
  • パスワード

を入力してSign up for GitHubをクリックします。

その後無料or有料を選び、メールアドレスを認証すれば登録は完了です。

個人で使うのであれば、まずは無料でOKだと思います。 ちなみに有料にすると、アップしたコードを非公開にもすることができます。

もしアカウントをすでに会社で作成されている、などといった場合は、Sign Inを押してログインしてみましょう。

新規登録orログインが全て完了すると、このような画面が表示されます。

f:id:awana1023:20181104184411p:plain

ターミナルのGitと自分のGitHubアカウントを紐づける

ユーザー情報をターミナルへ登録

以下のコマンドをターミナルで叩き、アカウント情報を登録します。

$ git config --global user.name "「ユーザ名」"
$ git config --global email.address "「メールアドレス」"

登録した情報の確認はこのコマンドでできます。

$ git config --list #全部確認
$ git config user.name #ユーザ名確認
$ git config email.address #メールアドレス確認

SSH鍵生成

ここまでの状況だと、誰かのGitHubのユーザ名とメールアドレスさえわかってしまえば、誰でもGitHubと通信が可能です。つまり、別人になりすますこともできてしまいます。

しかし実際にはそんなことは起きません。 なぜなら、自分のターミナルでSSH鍵(秘密鍵と公開鍵のペアになっている)を生成し、その公開鍵をGitHubアカウントに登録しておくことで、自分が持つ秘密鍵GitHubアカウントの公開鍵のペアが一致しなければ、通信できないようになっているからです。

その方法を説明します。

まずはターミナル上でSSH鍵セットを生成します。

$ ssh-keygen -t rsa -b 4096 
Enter file in which to save the key (/Users/hogehoge/.ssh/id_rsa): 

SSH鍵の名前を聞かれます。デフォルトはid_rsaであり、そのままでよければEnterを押して構いません。違う名前にしたい場合は以下のように名前を入力してからEnterを押します。 SSH鍵を生成する機会はGitHubの使用時に限りませんので、これがGitHubの鍵だ!とわかるようにしておくのがおすすめです。

Enter file in which to save the key (/Users/hogehoge/.ssh/id_rsa): /Users/hogehoge/.ssh/id_rsa_github

パスフレーズの設定

名前を決めたら、パスフレーズを入力します。パスフレーズなしで鍵を生成することも可能ですが、安全面強化のため設定することが望ましいです。 同じパスフレーズを2度入力します。画面には表示されないので気をつけて入力しましょう。

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

これが完了すると、 * 公開鍵(.pubがついている) * 秘密鍵 のセットが/Users/hogehoge/.ssh配下に生成されます。 秘密鍵は自分しかアクセスできないところに配置してなくさないようにしてください。

秘密鍵パーミッションを600(自分のみが読み取り、書き出し可能)に設定します。

$ chmod 600 ~/.ssh/id_rsa_github

以下のコマンドで確認します。 -rw-------と表示されればOKです。

$ ls -la ~/.ssh/id_rsa_github
-rw-------  1 hogehoge  staff  **** 11 4 12:34 /Users/hoge/.ssh/id_rsa_github

ターミナルで使用する鍵の設定

ssh-agentに鍵を登録します。 ここに秘密鍵を登録すると、パスフレーズを毎回登録する必要がなくなります! 登録は以下のコマンドで行います。

$ ssh-add ~/.ssh/id_rsa_github

ここでパスフレーズを聞かれます。

$ ssh-add -l 

で登録した鍵が表示されていたらOKです。

参考URL:ssh-agentの使い方 - Qiita

GitHubに公開鍵を登録する

作成した公開鍵をGitHubに登録します。 公開鍵をエディタで開いて中の文字列をコピーします。 (余計なスペースや改行etcが入らないように注意!)

ブラウザのGitHub画面の右上のアイコンをクリックし、「Settings」を開きます。

f:id:awana1023:20181104184530p:plain

左側にある「SSH and GPG keys」をクリックします。

f:id:awana1023:20181104184912p:plain

「New SSH key」をクリックして新しいSSH鍵を追加します。

  • Title:ここはなんでもいいです。どのPCにある公開鍵かわかるようにしておくのがおすすめです。
  • Key:コピーしてきた公開鍵を貼り付けます。

入力が完了したら「Add SSH key」をクリックします。

f:id:awana1023:20181104184946p:plain

SSH接続できるか確認する

ターミナルで以下のコマンドを入力します。

$ ssh GitHub

The authenticity of host 'github.com (192.30.255.112)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes
Hi awn-km23! You've successfully authenticated, but GitHub does not provide shell access.

このようにYou've successfully authenticatedと表示されればOKです。

The authenticity of host 'github.com (192.30.255.112)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)?

このような警告が出る場合があります。

「まだこのIP(今回ならGitHub)に接続したことがないよ!接続しちゃっても大丈夫?」という警告です。 もちろん大丈夫なので、yesと入力して進みましょう。

ひとまず完了です

ここまでで、Gitをターミナルで使う準備は完了です! おつかれさまでした!

次回記事では、 「コマンドでのリポジトリクローンから初めてのプルリクまで」を解説していく予定です!

参考URL