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
Ordinary Practices
Search
wtnabe
October 19, 2013
Programming
0
390
Ordinary Practices
Kanazawa.rb meetup #14 で話したいつものプラクティスです。分かってる人にとっては当たり前のことだらけです。これと言って何か新しい発見はないと思います。
wtnabe
October 19, 2013
Tweet
Share
More Decks by wtnabe
See All by wtnabe
Effective Jekyll
wtnabe
0
47
5 min Jekyll/Liquid Plugin cooking
wtnabe
0
22
Ruby de Wasm
wtnabe
0
46
Cloud Native Buildpacksって結局どうなの?
wtnabe
0
38
Decoupled System with Turbo Frame
wtnabe
1
120
join-kanazawarb-or-7years-passed-since-it-was-borned
wtnabe
0
770
let-me-edit-with-editor
wtnabe
0
330
google-photos-and-storage-and-rclone
wtnabe
0
440
one case of how to begin vuejs
wtnabe
2
460
Other Decks in Programming
See All in Programming
関数型まつりレポート for JuliaTokai #22
antimon2
0
150
データの民主化を支える、透明性のあるデータ利活用への挑戦 2025-06-25 Database Engineering Meetup#7
y_ken
0
320
Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール? 〜
yodakeisuke
0
100
A2A プロトコルを試してみる
azukiazusa1
2
1.1k
XP, Testing and ninja testing
m_seki
3
180
git worktree × Claude Code × MCP ~生成AI時代の並列開発フロー~
hisuzuya
1
450
プロダクト志向ってなんなんだろうね
righttouch
PRO
0
160
来たるべき 8.0 に備えて React 19 新機能と React Router 固有機能の取捨選択とすり合わせを考える
oukayuka
2
850
GraphRAGの仕組みまるわかり
tosuri13
7
480
F#で自在につくる静的ブログサイト - 関数型まつり2025
pizzacat83
1
310
GitHub Copilot and GitHub Codespaces Hands-on
ymd65536
1
120
CursorはMCPを使った方が良いぞ
taigakono
1
170
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Done Done
chrislema
184
16k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
16
940
Rails Girls Zürich Keynote
gr2m
94
14k
It's Worth the Effort
3n
185
28k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
53k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
How to Think Like a Performance Engineer
csswizardry
24
1.7k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Thoughts on Productivity
jonyablonski
69
4.7k
Transcript
ぼくのやってる ふつうのこと @wtnabe Kanazawa.rb meetup #14 2013-10-19 (Sat) at DMM.com
Labo Kanazawa
お品書き
ざっくり Web開発のプラクティス 使ってるツール 本当に⼤切なプラクティス
ざっくり TDDとend-to-endテストの話多め 最後の話だけ覚えて、あとは適当に
Web開発のプラクティス1 バージョン管理 Tickets & Milestones deployの⾃動化
Web開発のプラクティス2 開発環境の仮想化と⾃動構築 Test-Driven Development Continuous Integration
使ってるツール1 Subversion ( Mercurial, Git ) Trac Capistrano Vagrant, Chef
使ってるツール2 Jenkins RSpec, SimpleTest, Jasmine, PhantomJS SimpleCov(RCov), PHPCPD, JSHint
Web開発のプラクティス
バージョン管理 全部⼊れる ログがあるので安⼼して忘れられる うまく⾏くかどうか分からない場合も元 に戻せるので安⼼ いわゆる共通ライブラリは別リポジトリ
Tickets & Milestones 〆切をMilestoneの締め⽇にしてタスクを その中に落とし込む 基本的に⼀つのタスク : ⼀つのチケット みんなが分かるようにする 「完了」可能なタスクにする
deployの⾃動化 ⼿作業はミスやブレに繋がる 「fiddlingを避けよ」『Release It !』p112 変なコツをなくす 誰がやっても同じになる
開発環境の仮想化と ⾃動構築 VMのセットアップから⾃動化 デザイナもLinux環境使ってます Win/Macの違いはもうありません
Test-Driven Development
の前に
どちらが本当? コードは触り続けると汚くなる コードは触り続けるときれいになる
どちらも本当
リファクタリング してますか?
リファクタリング “外から⾒えるふるまいを変えずに、ソフトウェ アをわかりやすくし、安いコストで変更できる ようにするために、ソフトウェアの内部構造に 加えられる変更。” 『リファクタリング: Rubyエディション』p76
あなたのコードは安⼼して 変更できますか?
TDD ⻑く使うコード、変更し続けるアプリは リファクタリングが重要 TDDはリファクタリングを最も効率よく ⾏う⽅法の⼀つ
TDD 完璧な⾃動化は⽬指さない カバレッジは場所によって0〜100% 機能の⼀部だけをテストできると捗る テストデータの⾃動⽣成やダブルの活⽤
Continuous Integration うっかりテスト実⾏漏れ防⽌ うっかり環境依存テスト防⽌ 静的解析便利
オススメ導⼊⼿順(案) バージョン管理 / deployの⾃動化 CI end-to-endテスト ユニットテスト
使ってるツール
Subversion 2006年くらいから(それ以前はCVS) Mercurial, Gitも⼀部併⽤ そのうちGitへ⼀本化するつもり
選択基準 当時は各種ツールのサポートがよかった GitのGUIは⻑らく貧弱だった コードホスティング、クラウド側の対応 はGitがイチバン
Trac Python製Issue Tracking System むしろSubversionはTracを使う理由 (CVSでは使えない)
Capistrano Ruby製deployツール 個⼈では2008年〜、組織では2011年〜 これを理由に関係者はRuby必須に 必須に RailsもPHPも
Vagrant, Chef Ruby製VM管理ツール + サーバ設定⾃動 化 開発環境構築の⾃動化と開発環境の統⼀ 「適当にVM作って設定漏れ」をなくす 昔からの⾃前ツールも組み合わせて テストにも絡んできます
Jenkins Continuous Integrationのスタンダード Java trunkを⾃動でテスト/静的解析 deployの記録も取るようにした
RSpec Ruby製テスティングフレームワーク BDDスタイル Ruby 1.8でも動く Railsと合わせて使うノウハウが多い けど、Rubyのコードならなんでもよい
SimpleTest PHP 4/5 両対応のフレームワーク ⾃前pear packaging 最新版はPHP 5⽤ ユニットテストとカバレッジ測定 レガシーなコードにはオススメ
RSpec + Capybara (end-to-end) with rspec-rails for PHP
Vagrant / RSpec + Capybara for PHP 開発環境の統⼀、URL完全⼀致 誰の環境でend-to-endテストを動かし ても同じように動作する
Railsでのノウハウを流⽤
Vagrant / RSpec + Capybara for PHP PHPのバージョンに依らない 「ど真ん中」なのでメンテナンスが放棄 される不安がほぼない
Jasmine JavaScript⽤BDDフレームワーク gemで⼊れられる spec書きやすさのためにCoffeeScriptも テストはブラウザで実⾏ 最近はPhantomJSと組み合わせて
PhantomJS Headless Webkit Browser 2012年からインストールが超簡単に Jasmineと組み合わせてCIに Capybara + Poltergeistでend-to-endに
SimpleCov(RCov) Rubyのカバレッジ測定 ⾃動化はしてません あくまで⽬安の把握にしか使ってません
PHPCPD PHPのコピペチェッカ CIで記録取り
JSHint JavaScriptの静的スタイルチェッカ 設定項⽬ありすぎてうざい ruby wrapper⾃作してrakeで呼んでる wtnabe/jshint4r Node.js不要 対応バージョンが古い><
静的解析や計測 特にいじりにくいコードはコピペ率が⾼ くてカバレッジが低いといった特徴が⾒ えてくる 数値で分かるので⽬標を決めやすい
本当に⼤切なプラクティス
覚えて帰ってください 不易と流⾏ 継続は⼒なり
不易と流⾏ もともと蕉⾵俳諧の理念の⼀つ 変化しない本質的なものの中にも新しい 変化を取り⼊れること。また変化を取り ⼊れ続けることこそが不易の本質。
不易と流⾏ 転じて教育の世界では「変わらないことも変わ ることもどちらも学ぶべき」と語られることが 多い。
例 流⾏ Node.js, Chef, PhantomJS 不易 イベントドリブン、⾮同期、⾃動化
継続は⼒なり
今⽇の話 急にできるようになった ものなどありません
さらに⾔えば
今回の話に新しいものは 特にありません
昔から⾔われていること
昔から やってる⼈はやってること
Travis CI登場から2年 github登場から5年 Rails / Selenium登場から来年で10年 CIのプラクティス登場から15年くらい "Refactoring"から来年で15年 SUnit登場から来年で20年
Ruby誕⽣から20年 WWW誕⽣から23年 DBMS登場から30年以上 オブジェクト指向誕⽣から35年以上
ツールは変わる
背景や⽂化は そう変わらない
より深く 継続的に学ぼう
ツールも知ろう ⽂化も知ろう
やってみよう
それこそを Kanazawa.rbの ⽂化にしよう
ありがとうございました
参考 Release It! 本番⽤ソフトウェア製品の設計とデプロ イのために リファクタリング: Rubyエディション