2018夏インターンの記事が書かれてた
from インターンが来てた 2018夏
書かれてた
楽しんでもらえてなにより
でも話半分に読むと良いと思う
人間は実際に苦しかった事をあまり正直に書けない物なので
正直この2人はおかしい
production releaseした機能が紹介されているが
それよりも多くのpull requestが色々議論した結果、closeされている
コイツこの機能が本当に欲しいと思っていて、不具合があったら即直すつもりあるのかな？という事を確認するために根掘り葉掘り質問したりもしていた
耐えれる精神を持っている人は少ないと思う
> 開発にすんなり入れた
このへんが重要だったのではないか？と思う事がいくつかある
ので書きます
用語を統一してある
Scrapboxのソースコード上での変数名、関数名、class名
UserScriptやUserCSSで触れる事になる部品の名前
社内Scrapboxにあるドキュメント上での、ページタイトルや用語
ScrapboxのUI上の説明テキストでの用語
/help-jpなどのドキュメントでの用語
過去に書かれたドキュメントやソースコードも、何かある度になるべく修正するようにしている
インターン前からある程度イメージできていたのではないか？
部品の名前や、内部の構造が
設計とインフラ
本番環境に近い開発環境が、ローカルですぐ再現・起動できる
Scrapbox → GitHub → CircleCI → chat opsでのデプロイ、という流れ
開発と運用の権限分離
詳細は大切なことはだいたいHerokuで学んだで説明している
OSS運営をイメージしている
もちろん社内からしかcommitできないが
機能に不満がある人が社内にいたとして、ちょっとした変更なら「じゃあそれプルリクください。ここをアレすればできます」と言えるようにしたい
あんまり言わないけど
それぐらい、setup→起動→pull requestまでを楽にしている
Gyazoをやってる
からも、それぞれ何件かpull requestが来ている
逆にもGyazoのリポジトリを覗きに行くようにしている
簡単な修正なら、自分で直してpull requestする
最近は、画像ページの下のコメント欄に日本語URLを書けるようにした
pull requestしづらい部分があったら、そこを直す
ドキュメントのミスとか、.gitignoreとか
日頃から練習してないとGyazo-Scrapboxの連携機能を作る時に困る