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
サービス開発の現場からOSSを生み出す思考技術 / genbaweb04
Search
Yuichi Goto
October 22, 2018
Programming
3
1.2k
サービス開発の現場からOSSを生み出す思考技術 / genbaweb04
プラットフォームサービスの成長を支える技術〜Web現場Meetup #4(2018/10/22)
Yuichi Goto
October 22, 2018
Tweet
Share
More Decks by Yuichi Goto
See All by Yuichi Goto
[Teaser] Type-Safe Lightweight DDD with Effect Schema
yasaichi
1
81
Google Cloud を用いたソフトウェア開発の内製化組織の早期立ち上げの実現 / Rapid Establishment of In-House Software Development Teams Using Google Cloud
yasaichi
1
680
[EN] Robust and Scalable API Gateway Built on Effect
yasaichi
3
230
Effectで作る堅牢でスケーラブルなAPIゲートウェイ / Robust and Scalable API Gateway Built on Effect
yasaichi
8
1.8k
あるRailsエンジニアがビジネスリーダーに転身するまで
yasaichi
8
2.7k
Active Recordから考える次の10年を見据えた技術選定 / Architecture decision for the next 10 years at PIXTA
yasaichi
50
20k
Active Recordから考える次世代のRuby on Railsの方向性 / Directions for the next generation of Ruby on Rails: From the viewpoint of its Active Record
yasaichi
38
20k
ピクスタのエンジニアリングとCircleCI / Software Engineering with CircleCI at PIXTA
yasaichi
1
380
Ruby on Railsの正体と向き合い方 / What is Ruby on Rails and how to deal with it?
yasaichi
143
90k
Other Decks in Programming
See All in Programming
Azure AI Foundryのご紹介
qt_luigi
1
210
선언형 UI에서의 상태관리
l2hyunwoo
0
270
責務を分離するための例外設計 - PHPカンファレンス 2024
kajitack
9
2.4k
週次リリースを実現するための グローバルアプリ開発
tera_ny
1
1.2k
PHPカンファレンス 2024|共創を加速するための若手の技術挑戦
weddingpark
0
140
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'just works' is good, but code that is 'readable' is even better.
mkmk884
6
1.4k
情報漏洩させないための設計
kubotak
5
1.3k
Fibonacci Function Gallery - Part 2
philipschwarz
PRO
0
210
Итераторы в Go 1.23: зачем они нужны, как использовать, и насколько они быстрые?
lamodatech
0
1.4k
技術的負債と向き合うカイゼン活動を1年続けて分かった "持続可能" なプロダクト開発
yuichiro_serita
0
300
DevinとCursorから学ぶAIエージェントメモリーの設計とMoatの考え方
itarutomy
0
150
良いユニットテストを書こう
mototakatsu
11
3.6k
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
What's in a price? How to price your products and services
michaelherold
244
12k
How to train your dragon (web standard)
notwaldorf
89
5.8k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
How to Ace a Technical Interview
jacobian
276
23k
Faster Mobile Websites
deanohume
305
30k
Typedesign – Prime Four
hannesfritz
40
2.5k
Learning to Love Humans: Emotional Interface Design
aarron
274
40k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Practical Orchestrator
shlominoach
186
10k
Visualization
eitanlees
146
15k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Transcript
サービス開発の現場から OSSを生み出す思考技術 Yuichi Goto (@_yasaichi) October 22, 2018 @ Web現場Meetup
#4
self.inspect @_yasaichi yasaichi http://web-salad.hateblo.jp ピクスタ株式会社 技術推進チームリーダー !2 一般的には「技術基盤」と 言われるようなチーム
本発表について 話すこと • 私がOSSの開発に至る までの思考パターン • 思考パターンを実際の 問題に適用した例 !3 話さないこと
• 紹介するOSSの詳細 • 原理の理解に必要な RubyやJSの知識 • 具体的な実装
Agenda 背景と目的 OSSを生み出す思考パターン 実際の適用例 まとめ !4
サービス開発の現場はOSSネタの宝庫 • 私(エンジニア歴4年目)の場合 • 今まで作ったOSSは8つ • 作成したOSSのほとんどが現場で直面した問題が きっかけで生まれたもの • 現場に立っているからこそ、開発者の問題を解決する
ソフトウェアを生み出せる !5
個人でOSSを開発・公開するメリット • 自身の能力を外部に示せる形で残せる • 一発当たれば有名(?)になれるかも • 開発する過程で少なからず学びや成長がある • 何かを拡張する場合、作る過程で対象に詳しくなる •
公開する前提で作るので良いプレッシャーがある !6
とはいえ • 経験上、誰もができるわけではなさそう • 技術的なスキルの問題というよりは、単に機会を 見逃していることが多いように見える • 現場の問題に対してどう向き合うか境目では? • 自身の思考パターンを共有することで誰かが良い
OSSを生み出すきっかけになれば嬉しい ☺ !7
Agenda 背景と目的 OSSを生み出す思考パターン 実際の適用例 まとめ !8
全体の流れ !9 解決策を説明する一文を考える ③ メタ認知 解決策が適用できる別の問題を探す ② 特化 問題をなるべく小さくして解く ①
汎化
フェーズ1: 汎化 • やること 目の前の問題をなるべく小さな別の問題にしてから、 それに対する解決策を考える • なぜやるのか 問題を小さくしようと意識すると、結果として汎用的な 解決策が生まれやすいため
!10
フェーズ2: 特化 • やること 得られた解決策が目の前の問題以外のケースにも 適用できないか考える • なぜやるのか 得られた解決策が汎用的かどうか確認するため !11
フェーズ3: メタ認知 • やること 得られた解決策をOSSとして公開したと仮定して、 提供する機能を説明する一文(英語)を考える • なぜやるのか 他者に説明しようと試みることで、得られた解決策の 有用性を客観的に捉えることできるため
!12 READMEを書いても良いが、もう 少しお手軽なこちらがおすすめ
Agenda 背景と目的 OSSを生み出す思考パターン 実際の適用例 まとめ !13
事例1: sass-var ॾࣄʹΑΓඇެ։ !14
事例2: gakubuchi https://github.com/yasaichi/gakubuchi • RailsのAsset Pipelineを利用して静的ページを 管理できるようにするgem • 開発のきっかけ メンテ前に
public/503.html を修正していた際に、 Viewを書くようにエラーページを書きたいと思った !15
思考の流れ: 汎化フェーズ !16 やりたいことを分解すると、テンプレートエンジンの利用、 外部CSS/JSの参照、ヘッダー等の再利用の3点 最後の「部分テンプレートの利用」さえ諦めれば、Asset Pipelineがそのまま使えそう。エラーページだしいいか Rakeにはタスクの前後に任意の処理を差し込むAPIがあ るので、エラーページをpublic以下に移す処理だけ書く
思考の流れ: 特化/メタ認知フェーズ !17 実装を工夫すれば、エラーページに限らず任意の静的 ページ(キャンペーンページ等)で同じ仕組みが使えそう 静的ページ全般で使えるので、一言で説明すると"Static pages management with Asset
Pipeline"かなあ よさそうなのでgemify! $
結果 !18 $ echo "gem 'gakubuchi'" >> Gemfile $ bundle
install &>/dev/null && bin/rails generate gakubuchi:install create config/initializers/gakubuchi.rb create app/assets/templates $ bin/rails assets:precompile &>/dev/null $ cat public/foo.html <link rel="stylesheet" media="all" href="/assets/application- f0d704deea029cf000697e2c0181ec173a1b474645466ed843eb5ee7bb215794.css" /> <%# app/assets/templates/foo.html.erb %> <%= stylesheet_link_tag 'application', media: 'all' %> precompileすると、外部CSSを参照 したHTMLがpublic以下にできる
番外編: grease https://github.com/yasaichi/grease • Tilt(テンプレートエンジンのAPIを統一するラッ パー)をSprockets v4でも動作させるアダプター • 開発のきっかけ(≠現場の問題) 事例2で紹介したgakubuchiで「Sprockets
v4で 動かないんですけど…」というIssueが立った !19 Asset Pipelineの実装に 使われているgem
思考の流れ !20 gakubuchiにSprockets v4対応のコードを足すのではな く、別のgemとして実装してこれを適用する形にする Tiltが対象としているテンプレートエンジンとSprocketsを 統合するgemを開発する場合にも同じように使えそう ニッチだが、"Tilt adapter for
Sprockets 3 or later"と いう一文でわかる人には絶対わかると信じてgemify! $
https://github.com/metaskills/less-rails/pull/137 !21 結果
何が起きた? • 特化フェーズでの読みがそのまま当たった • less-rails(RailsでLessを使うためのgem)での Sprockets v4対応にgreaseが利用された • 結果、35万ダウンロードの私的最大ヒット作に ✌
• "問題を小さくしようと意識すると、結果として汎用的 な解決策が生まれる"ことを身をもって実感した !22
Agenda 背景と目的 OSSを生み出す思考パターン 実際の適用例 まとめ !23
まとめ • サービス開発現場の問題をきっかけにOSSの開発に 至るまでの私の思考パターンを紹介した • 汎化→特化→メタ認知の3フェーズで成り立つ • 各フェーズにおいて考えるべきことがある • この思考パターンを実際の問題に適用した例を3つ
紹介し、その効果を示した !24
ご清聴ありがとうございました !25