Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
14日間でサクサクっとOSSをリリースした話 / Talking of releasing O...
Search
kamontia
September 20, 2018
Programming
2
380
14日間でサクサクっとOSSをリリースした話 / Talking of releasing OSS in 14 days
kamontia
September 20, 2018
Tweet
Share
More Decks by kamontia
See All by kamontia
Super beginners for MQTT
kamontia
0
28
Other Decks in Programming
See All in Programming
パスキーのすべて ── 導入・UX設計・実装の紹介 / 20250213 パスキー開発者の集い
kuralab
3
870
もう僕は OpenAPI を書きたくない
sgash708
5
1.9k
Kotlinの開発でも AIをいい感じに使いたい / Making the Most of AI in Kotlin Development
kohii00
2
220
PRレビューのお供にDanger
stoticdev
1
220
Djangoアプリケーション 運用のリアル 〜問題発生から可視化、最適化への道〜 #pyconshizu
kashewnuts
1
260
Datadog Workflow Automation で圧倒的価値提供
showwin
1
100
一休.com のログイン体験を支える技術 〜Web Components x Vue.js 活用事例と最適化について〜
atsumim
0
790
5分で理解する SOLID 原則 #phpcon_nagoya
shogogg
1
280
密集、ドキュメントのコロケーション with AWS Lambda
satoshi256kbyte
1
210
Rails アプリ地図考 Flush Cut
makicamel
1
130
Kubernetes History Inspector(KHI)を触ってみた
bells17
0
250
Grafana Loki によるサーバログのコスト削減
mot_techtalk
1
140
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Facilitating Awesome Meetings
lara
52
6.2k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
100
18k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
GitHub's CSS Performance
jonrohan
1030
460k
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
A designer walks into a library…
pauljervisheath
205
24k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.4k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
430
Why Our Code Smells
bkeepers
PRO
336
57k
Transcript
14日間でサクサクっと OSSをリリースした話 2018/9/20@Study Sapuri Lab kamontia 1
自己紹介 2 Name Tatsuya Kamohara(@kamontia) Work とあるSIerの5年目 車載(Linux)組み込みエンジニア のわりに上位レイヤー好き Hobby
ダーツ レーティング7付近(3投に1投真ん中くらい) Other 最近一児の父親になりました
3 今回の発表は @chaspy(大学同期)と 一緒に開発した話である
何を作ったのか ワンライナーでGitのコミットをsquashするCLIツール • Golang製 4 プログラミング言語別の年収ランキング、中央値1位は「Go」 http://www.itmedia.co.jp/news/articles/1808/07/news087.html QUICK SQUASH
作成したツールの使いどころ 5 機能A追加 Typo修正 型変更 機能A1追加 Typo修正 ブランチで作業するときは、こまめにコミット(セーブポイント)を作りがち もちろんコミット単位を考えて作業出来ることが大切 けど、ビビリだからこまめにセーブしたい
作成したツールの使いどころ 6 機能A追加 Typo修正 型変更 機能A1追加 Typo修正 PRするときにレビューアに「コミットログ、キレイにしてからPR出してね」 とか、「結局これは機能Aについてのコミットだからまとめられるな」と 自分で気づく。あるあるである。
機能A追加
7 1つのコミットに まとめたい時 普通だったらこうする
git rebase コマンドを使う 8
Git Editorが開く 9
まとめたいコミットを「pick」→「squash(s)」 10
不要なメッセージを削除 11
「1つのコミットにまとめたよ」に決定 12
コミットがまとまった! 13
14 このシチュエーション続くと 結構めんどい
15 QUICK SQUASHなら ワンライナーで出来る
QUICK SQUASHコマンドを試す 16 qs –n i..j -m “message” i..j-1のコミットを j
に-mで指定した コミットログでまとめる
17 QUICK SQUASHなら ワンライナーで出来る
なぜ作ろうと思ったのか • 社会人5年目に突入しちゃったよ! – 業務はテストや受け入れが多い・・・ – でも、技術は追いかけていきたい – 隣の席の先輩がすごい…けど自分は無力だ –
とにかく誰かの役に立ちたい! 18 気づくとさまざまな思いや悩みが “ちりつも” していた
19 OSSでちょっとでも 貢献できないか?
20 実は今までも 数回OSS開発に 挑戦していた
21 でもリリースまで 至らなかった
でもリリースまで 至らなかった 22 WHY?
作れなかった理由 • 形から入ろうとした – OSS開発といったらGit+GitHubが主流 – 相談出来る人が近くにいない状態で「はじめてのGit」 → 当然、Gitが足かせになってやる気喪失 •
スタートラインが揃っていなかった – 共通認識が薄く、時間経過により自然消滅 – コミュニケーションが維持しにくかった(物理的距離や都合) 23 そして業務が忙しくなり、モチベーション低下
今回リリースまで至った理由(ここを変えた) • Gitをある程度理解した – 本当に便利! – じゃあよく使ってるGit rebaseを便利するツールを作ろう ⇨ モチベーション高かった
• 様々なツールを上手に活用できた 24 モチベーションを維持することができた
利用したサービスやツール • Git + Github – これは言わずもがな • Slack –
コミュニケーションツール – Githubと連携して通知 • HackMD – BIG PICTUREを素早く共有 • Visual Studio Code – リモートペアプログラミング 25 各自頑張ってるのが分かる わざわざ知らせる必要もない 今回 紹介したい内容の1つ
26 リモートペアプログラミング の前に ペアプロって?
ペアプログラミング 27 ペアプログラミングとは、2人でプログラミング(および分析、設計、テスト)と プログラムの改良を同時に行うやりとりのことである。 Kent Beck、Cynthia Andres著/角征典訳『エクストリームプログラミング』オーム社、2015、p.40 • コードの質が向上する •
問題解決が速い • 開発Tipsの共有 – そのショートカット何?みたいな But… • 場所を共有する必要がある
28 そこでリモート!
29 リモートペアプログラミング ってどうせ 画面共有するんでしょ?
30 「387行目の条件分岐のところの~」 「あ、そこじゃなくてもう少し後ろの…」 「んーちょっと行き過ぎ~」 「あ、うんうんそこそこ」 ってなるんでしょ?
31 今回紹介するのは ちょっとだけ進んでます
How to リモートペアプログラミング • 必要なもの – Visual Studio Code (AtomでもたぶんOK)
– VS Live Share (Teletype for AtomでもたぶんOK) – 快適な回線(RTTが小さい方がいい) 32
セットアップ 33 ①コマンドパレットで「live」で検索 ② MicrosoftかGithubのアカウントでログイン
やってみる 34 ④ 招待用のURLをコピーして 相手にSlackなどで送る ③ セッションを開始する ⑤ URLをクリックすると自動でエディタが立ち上がる
実際の動作デモ 35 自分のPC 相手のPC
リモートペアプログラミングをやってみて • 大学時代の友人とのOSS開発に使ってみたら とても捗った 僕の今までのあるある – 最初につまづくとやる気無くなる ⇨ 解決が速い! –
事前に決めたことと、ちょっと違う実装になる(=認識がズレてる) ⇨ 実装レベルで認識が合う!モチベーション維持できる! それに「リモート」だと ペアプログラミングの恩恵を簡単に受けることができる 36
Go言語を選んだ理由 開発の側面 • 2人のスタートを出来るだけ一緒にしたかった – 片方が詳しすぎると任せてしまう恐れ • チュートリアルがシンプルだった – tour
of goを8割程度さらっと読んだ – ドットインストール1周した 37
Go言語を選んだ理由 言語仕様や思想の側面 • クロスコンパイルに対応 – 1つのソースコードでWindowsやMac、Linuxに展開可能 • シングルバイナリで動く – 配布が楽チン
• コーディングフォーマットが言語仕様に含まれている – 書き方が強制される – 本質的なところに集中できる 38
まとめ モチベーションの維持は大切 仕事を定時で終わらせて早く開発したい と思えたらとりあえず大丈夫(な気がする) そのために出来ること • 一人ではなく仲間を作る – @chaspy に感謝
• 使えるツールは積極的に使う – 遠い距離=障壁になることはない – Gitは必要条件にはならないが、絶対覚えておくべき • 言語の選定も大事 – リリースまでの期間に影響は与える • リリースに時間がかかるとモチベーションは下がる 39
ちょっとだけ宣伝 • Qiita – 最速でgit-rebaseするコマンドQS(quick squash)を 作ってみた – https://qiita.com/kamontia/items/ac5c7f99599049b545e9 40
41 ありがとうございました