GitHubで複数行に対してコメントをつけることができるようになったそうですよー！
Multi-line comments have arrived!
— GitHub (@github) October 1, 2019
You can now highlight multiple lines in a pull request diff and add a comment, all at once. pic.twitter.com/nqIgdBkRql
むしろ今まで何でできないんだろうと思ってました。プログラマの人にとってはそういうものなのかしら…私が初心者だからその感覚がわからないのかしら？と思ってました（笑）
GitHubから「One of your dependencies has a security vulnerability」（package-lock.jsonで指定されてるパッケージに脆弱性があるよー）というアラートがきたので対応した手順をメモしておきます。
更新したいpackage.jsonがあるディレクトリで以下を実行
$ npm-check-updates -u --packageFile package.jsonこれで package.json の内容が書き換わる。
（npm-check-updates 自体がインストールされていなくて使えない場合は $ npm install -g npm-check-updates から。参考： npm入門 - Qiita ）
次に npm update 。これで実際にパッケージが更新される。
$ npm updateそしたら脆弱性が見つかったって言われた
found 48 vulnerabilities (1 low, 47 high)
run `npm audit fix` to fix them, or `npm audit` for detailsなので npm audit fix
$ npm audit fixこれで、自動的にアップデートして対処できるものは対処してくれる。
npm audit すると今残ってる脆弱性の詳細を教えてくれる。こんな感じ。
$ npm audit
=== npm audit security report ===
Manual Review
Some vulnerabilities require your attention to resolve
Visit https://go.npm.me/audit-guide for additional guidance
Low Regular Expression Denial of Service
Package braces
Patched in >=2.3.1
Dependency of babel-cli
Path babel-cli > chokidar > anymatch > micromatch > braces
More info https://nodesecurity.io/advisories/786
found 1 low severity vulnerability in 3390 scanned packages
1 vulnerability requires manual review. See the full report for details.じゃあこの残ってるパッケージをどうしたらいいかっていうのはまた今度調べます… low severity なので。
緊急度が高いものはパッケージの開発者の方々もチェックして対応してくれていることが多いので、そのおかげで自動でアップデートできるみたいです。
My first PR to an open source project was successfully merged. The repo it got merged into was dev.to!
Add GitLab URL field to user profile by sidemt · Pull Request #1121 · thepracticaldev/dev.to
I added a new field to put a link to GitLab profile on DEV profile.
@ben gave me a comment on GitHub so I wrote the changelog post for it too.
Changelog: Add GitLab link to your profile - DEV Community
As many of you may know dev.to uses Ruby on Rails. I have learned the basics of Rails and have made a few web apps as personal projects but had never worked on such a large project.
But there already were similar URL fields and one of them was added recently so I could easily find out what I needed to change by looking into the PRs and codes of the other fields.
The most difficult part for me was setting up the environment locally.
I'm a Windows user.
As far as I know, I can't install rbenv on Windows. So I used WSL(Windows Subsystem for Linux).
There is a detailed guide in dev.to's documentation. It helped me a lot.
I'm thinking of writing detailed posts on how I resolved these troubles later.
rbenv but I couldn't resolve it. After investigating for a whole day I decided to reset the WSL and installed everything again (I could do this because dev.to was the only project I'm using WSL)After going through these challenges, I finally submitted the PR.
The code I added was 30 lines or so. 90% of my work was setting up the environment.
But as a code newbie who has no work experience as a developer, I learned a lot from this installation process.
When you create something by yourself you would use something you know or have heard of. Going through all the errors, I had many chances to deal with things I had no idea what they were.
Many "things I don't even know they exist" became "things I have heard of their name" and "things I kind of know what they do". I can now guess "I might be able to do this using this..." and search for it more easily.
If you are a beginner in programming, I recommend you trying to set up a development environment of a large open source project. Even if you can't eventually submit a PR, you can get an idea of what a real-world project looks like, you can practice reading the error message and searching for solutions, you can see the names of a huge number of modules which might help you in the (near) future.
Actually, I was considering to submit my first PR to freeCodeCamp at first (But I couldn't find "first timers welcome" issues available. I was lucky to find an entry-level issue here!) so I recently installed its environment too. These experience made me think that setting up a local environment of open source projects may be a good practice for beginners.
I use GitLab for my private repositories. It's free!
If you are a GitLab user please try adding the link to GitLab on your DEV profile!
初めてオープンソースのプロジェクトにPRを出してマージされました！嬉しい！！
Add GitLab URL field to user profile by sidemt · Pull Request #1121 · thepracticaldev/dev.to
DEV Community (dev.to) という、英語圏のMediumとQiitaの中間みたいな感じのサービスの機能追加にコントリビュートしました。
DEV Community (https://dev.to/)
日本のTwitterでも話題になったことがあるようで、時々名前を見かけるので結構知られているのかなと。
（周りにエンジニア系のリアル知り合いがいない初心者なものでその辺の温度感が分かりません…）
dev.toのプロフィールにGitLabのプロフィールへのリンクを追加できるようにしました。
Changelogの投稿もして良いですよとコメントいただいたので簡単にですが投稿させていただきました。
Changelog: Add GitLab link to your profile - DEV Community
Ruby on Railsのプロジェクトです。
こんな大規模なプロジェクトのコードに変更を加えるのは初めてだったのですが、同様の入力欄がすでに多数あり、最近も追加されていたので、その時の変更内容や他の欄のコードを参考にして書くことができてそんなに難しくありませんでした。
難しかったのは環境構築でした。
まずWindowsユーザーなのですが、たぶんRails(Ruby)をやるには向いてないんですよね。Windows。今回すごい実感して今後の方向性考えたほうがいいのかなと思いました（笑）
今回WSL(Windows Subsystem for Linux)を使って、
という形にしました。dev.to公式のドキュメントでこの方法も書いてあって助かりました。
このあたりの詳しい躓きポイントと解決した方法は別途記事にできたらいいなと思ってます。
rbenv のバージョンがおかしなことになってるのは分かったけれど1日やって直せなくて結局WSLをリセットしてインストールしなおす（このプロジェクトしかやってなかったからできる解決策）→で、ようやくPR出せました。
追加したコードは数十行で、作業時間の9割くらいは環境構築を試行錯誤していたのですが（笑） 実務経験の無い初心者としてはこのおかげで学ぶものが大きかったです。
自分一人で何か作っても、自分が全く知らないものを無理やりにでも触って動かすという経験はなかなかできないので。
例えば実際にPRを出すところまでまだ行けなくても、大規模なオープンソースプロジェクトの開発環境をローカルに構築して起動するようにしてみるだけでも、「実務の世界で使われているようなコードはこんな規模なんだ（きっと）」と感じることができ、エラーメッセージから解決策を調べる練習にもなり、いろんなモジュールの名前を目にすることもでき。学べたことが多々ありました。
存在すらしらない→名前だけは見たことがある→どういう系の機能で使われるものかなんとなく分かる、という状態にできると、自分が「こんなことを実現したい」と思ったときに格段に調べやすくなると思っているので、オススメです。
実は最初初めてPRを出すリポジトリは freeCodeCamp にしようと思ってそちらの環境構築もしていたので、比較的短期間に異なる言語・フレームワークのプロジェクトの環境構築を2回やって、そんなことを感じました。
dev.toお使いの方、ぜひGitLabのURL追加してみてください！
cloud9からGitHubに push しようとしたらこんなエラーに遭遇しました。
remote: error: GH007: Your push would publish a private email address. remote: You can make your email public or disable this protection by visiting: remote: http://github.com/settings/emails To https://github.com/*****/*****.git ! [remote rejected] master -> master (push declined due to email privacy restrictions) error: failed to push some refs to 'https://github.com/*****/*****.git'
「このまま push すると private のメールアドレスが公開されちゃうけど良いの？
そのメールアドレスを public に変更するかこのエラーを出す設定をオフにしてね！」的なエラーメッセージ。
GitHubのこの画面の設定のことを言っているようです。
public にしたくないアドレスだし今後もこのエラーは出し続けてほしいので、
現在のメールアドレス設定を確認。
$ git config --global user.email
すると、以前ちゃんと変えたつもりがまた公開したくないアドレスになっている。
cloud9 の workspace を変えるともとに戻ってしまう様子？これはどの設定のメールアドレスから引っ張ってきてるのかあとで確認しよう…
ダミーのアドレスに設定
$ git config --global user.email "*****@users.noreply.github.com"
メールアドレスは commit 時に記録されているようで、このまま再push しても同じエラーが出ました。なので一旦 commit を取り消します。
ワークディレクトリの内容はそのままでコミットだけを取り消し
$ git reset --soft HEAD^^
これで add された状態にもどりましたが、ちょっと add からやり直したい事情が出てきたので（コミットを分けたかった）
$ git reset HEAD
で一旦 add も取り消し。
で、 add→commit をやり直すと問題なく push できました。
git log のメールアドレスもちゃんと変わっていることを確認。
参考：
GitHub でダミーのメールアドレスを使用する
https://qiita.com/sta/items/982ab68e8220a81d485c
[Git]コミットの取り消し、打ち消し、上書き
https://qiita.com/shuntaro_tamura/items/06281261d893acf049ed
git の add を取り消す
https://qiita.com/nabezokodaikon/items/7ee4900d28d8d863978e
※ちなみに一番最初のコミットは取り消し方が異なる。
$ git update-ref -d HEAD
参考：
初回のコミットを取り消したいときにはgit update-refを使う
https://suzuken.hatenablog.jp/entry/2014/03/28/100311