14日間でサクサクっとOSSをリリースした話 / Talking of releasing OSS in 14 days

Transcript

1. 14日間でサクサクっと OSSをリリースした話 2018/9/20@Study Sapuri Lab kamontia 1
2. 自己紹介 2 Name Tatsuya Kamohara(@kamontia) Work とあるSIerの5年目 車載(Linux)組み込みエンジニア のわりに上位レイヤー好き Hobby ダーツ レーティング7付近(3投に1投真ん中くらい) Other 最近一児の父親になりました
3. 3 今回の発表は @chaspy(大学同期)と 一緒に開発した話である
4. 何を作ったのか ワンライナーでGitのコミットをsquashするCLIツール • Golang製 4 プログラミング言語別の年収ランキング、中央値1位は「Go」 http://www.itmedia.co.jp/news/articles/1808/07/news087.html QUICK SQUASH
5. 作成したツールの使いどころ 5 機能A追加 Typo修正 型変更 機能A1追加 Typo修正 ブランチで作業するときは、こまめにコミット(セーブポイント)を作りがち もちろんコミット単位を考えて作業出来ることが大切 けど、ビビリだからこまめにセーブしたい
6. 作成したツールの使いどころ 6 機能A追加 Typo修正 型変更 機能A1追加 Typo修正 PRするときにレビューアに「コミットログ、キレイにしてからPR出してね」 とか、「結局これは機能Aについてのコミットだからまとめられるな」と 自分で気づく。あるあるである。 機能A追加
7. 7 1つのコミットに まとめたい時 普通だったらこうする
8. git rebase コマンドを使う 8
9. Git Editorが開く 9
10. まとめたいコミットを「pick」→「squash(s)」 10
11. 不要なメッセージを削除 11
12. 「1つのコミットにまとめたよ」に決定 12
13. コミットがまとまった！ 13
14. 14 このシチュエーション続くと 結構めんどい
15. 15 QUICK SQUASHなら ワンライナーで出来る
16. QUICK SQUASHコマンドを試す 16 qs –n i..j -m “message” i..j-1のコミットを j に-mで指定した コミットログでまとめる
17. 17 QUICK SQUASHなら ワンライナーで出来る
18. なぜ作ろうと思ったのか • 社会人5年目に突入しちゃったよ！ – 業務はテストや受け入れが多い・・・ – でも、技術は追いかけていきたい – 隣の席の先輩がすごい…けど自分は無力だ – とにかく誰かの役に立ちたい！ 18 気づくとさまざまな思いや悩みが “ちりつも” していた
19. 19 OSSでちょっとでも 貢献できないか？
20. 20 実は今までも 数回OSS開発に 挑戦していた
21. 21 でもリリースまで 至らなかった
22. でもリリースまで 至らなかった 22 WHY?
23. 作れなかった理由 • 形から入ろうとした – OSS開発といったらGit+GitHubが主流 – 相談出来る人が近くにいない状態で「はじめてのGit」 → 当然、Gitが足かせになってやる気喪失 • スタートラインが揃っていなかった – 共通認識が薄く、時間経過により自然消滅 – コミュニケーションが維持しにくかった(物理的距離や都合) 23 そして業務が忙しくなり、モチベーション低下
24. 今回リリースまで至った理由(ここを変えた) • Gitをある程度理解した – 本当に便利！ – じゃあよく使ってるGit rebaseを便利するツールを作ろう ⇨ モチベーション高かった • 様々なツールを上手に活用できた 24 モチベーションを維持することができた
25. 利用したサービスやツール • Git + Github – これは言わずもがな • Slack – コミュニケーションツール – Githubと連携して通知 • HackMD – BIG PICTUREを素早く共有 • Visual Studio Code – リモートペアプログラミング 25 各自頑張ってるのが分かる わざわざ知らせる必要もない 今回 紹介したい内容の１つ
26. 26 リモートペアプログラミング の前に ペアプロって？
27. ペアプログラミング 27 ペアプログラミングとは、2人でプログラミング（および分析、設計、テスト）と プログラムの改良を同時に行うやりとりのことである。 Kent Beck、Cynthia Andres著／角征典訳『エクストリームプログラミング』オーム社、2015、p.40 • コードの質が向上する • 問題解決が速い • 開発Tipsの共有 – そのショートカット何？みたいな But… • 場所を共有する必要がある
28. 28 そこでリモート！
29. 29 リモートペアプログラミング ってどうせ 画面共有するんでしょ？
30. 30 「387行目の条件分岐のところの～」 「あ、そこじゃなくてもう少し後ろの…」 「んーちょっと行き過ぎ～」 「あ、うんうんそこそこ」 ってなるんでしょ？
31. 31 今回紹介するのは ちょっとだけ進んでます
32. How to リモートペアプログラミング • 必要なもの – Visual Studio Code (AtomでもたぶんOK) – VS Live Share (Teletype for AtomでもたぶんOK) – 快適な回線(RTTが小さい方がいい) 32
33. セットアップ 33 ①コマンドパレットで「live」で検索 ② MicrosoftかGithubのアカウントでログイン
34. やってみる 34 ④ 招待用のURLをコピーして 相手にSlackなどで送る ③ セッションを開始する ⑤ URLをクリックすると自動でエディタが立ち上がる
35. 実際の動作デモ 35 自分のPC 相手のPC
36. リモートペアプログラミングをやってみて • 大学時代の友人とのOSS開発に使ってみたら とても捗った 僕の今までのあるある – 最初につまづくとやる気無くなる ⇨ 解決が速い！ – 事前に決めたことと、ちょっと違う実装になる(=認識がズレてる) ⇨ 実装レベルで認識が合う！モチベーション維持できる！ それに「リモート」だと ペアプログラミングの恩恵を簡単に受けることができる 36
37. Go言語を選んだ理由 開発の側面 • 2人のスタートを出来るだけ一緒にしたかった – 片方が詳しすぎると任せてしまう恐れ • チュートリアルがシンプルだった – tour of goを8割程度さらっと読んだ – ドットインストール1周した 37
38. Go言語を選んだ理由 言語仕様や思想の側面 • クロスコンパイルに対応 – 1つのソースコードでWindowsやMac、Linuxに展開可能 • シングルバイナリで動く – 配布が楽チン • コーディングフォーマットが言語仕様に含まれている – 書き方が強制される – 本質的なところに集中できる 38
39. まとめ モチベーションの維持は大切 仕事を定時で終わらせて早く開発したい と思えたらとりあえず大丈夫(な気がする) そのために出来ること • 一人ではなく仲間を作る – @chaspy に感謝 • 使えるツールは積極的に使う – 遠い距離＝障壁になることはない – Gitは必要条件にはならないが、絶対覚えておくべき • 言語の選定も大事 – リリースまでの期間に影響は与える • リリースに時間がかかるとモチベーションは下がる 39
40. ちょっとだけ宣伝 • Qiita – 最速でgit-rebaseするコマンドQS(quick squash)を 作ってみた – https://qiita.com/kamontia/items/ac5c7f99599049b545e9 40
41. 41 ありがとうございました