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
RubyConf Uruguay 2013 - New York, New York
Search
Patricio Mac Adden
March 23, 2013
Programming
2
100
RubyConf Uruguay 2013 - New York, New York
Patricio Mac Adden
March 23, 2013
Tweet
Share
Other Decks in Programming
See All in Programming
PHPで TLSのプロトコルを実装してみる
higaki_program
0
590
AWS×クラウドネイティブソフトウェア設計 / AWS x Cloud-Native Software Design
nrslib
16
3.5k
PHPのバージョンアップ時にも役立ったAST(2026年版)
matsuo_atsushi
0
270
Linux Kernelの1文字のミスで 権限昇格ができた話
rqda
0
2.2k
Codex CLIのSubagentsによる並列API実装 / Parallel API Implementation with Codex CLI Subagents
takatty
2
720
Codexに役割を持たせる 他のAIエージェントと組み合わせる実務Tips
o8n
4
1.4k
The free-lunch guide to idea circularity
hollycummins
0
390
Ruby and LLM Ecosystem 2nd
koic
1
1.4k
仕様漏れ実装漏れをなくすトレーサビリティAI基盤のご紹介
orgachem
PRO
8
3.6k
What Spring Developers Should Know About Jakarta EE
ivargrimstad
0
800
テレメトリーシグナルが導くパフォーマンス最適化 / Performance Optimization Driven by Telemetry Signals
seike460
PRO
2
200
野球解説AI Agentを開発してみた - 2026/02/27 LayerX社内LT会資料
shinyorke
PRO
0
370
Featured
See All Featured
First, design no harm
axbom
PRO
2
1.1k
The #1 spot is gone: here's how to win anyway
tamaranovitovic
2
1k
エンジニアに許された特別な時間の終わり
watany
106
240k
Git: the NoSQL Database
bkeepers
PRO
432
67k
The B2B funnel & how to create a winning content strategy
katarinadahlin
PRO
1
310
Bootstrapping a Software Product
garrettdimon
PRO
307
120k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
510
Designing for Performance
lara
611
70k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Ethics towards AI in product and experience design
skipperchong
2
240
Jess Joyce - The Pitfalls of Following Frameworks
techseoconnect
PRO
1
120
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Transcript
New York, New York
Patricio Mac Adden
[email protected]
maxawen
None
Esta charla es sobre Sinatra...
... y sobre buenas prácticas
“Is a DSL for quickly creating web-applications in Ruby.” -
Documentación oficial - Sinatra
Sinatra: routes
Sinatra: views
Sinatra: views
Sinatra: static files
Sinatra: static files
Sinatra: static files
Sinatra: filters
Sinatra: helpers
Sinatra: helpers
Sinatra: configuration
Sinatra: environments
Sinatra: error handling
Sinatra: classic
Sinatra: modular
Sinatra: rides on Rack
Pero...
“It isn’t a typical Model-View-Controller framework, but ties specific URL
directly to relevant Ruby code and returns its output in response. It does enable you, however, to write clean, properly organized applications: separating views from application code, for instance.” - Documentación oficial - Sinatra
Sin estructura de directorios por defecto
Sin ORM por defecto
Sin base de datos por defecto
Sin tasks
Sin test framework por defecto
¡No decide nada por nosotros!
Sinatra es ideal para prototipos, APIs y aplicaciones pequeñas
Pero también para aplicaciones grandes, ¿por qué no?
El problema
Sinatra es flexible
Desorden
¿Como organizar los controllers?
Uso inconsistente del DSL
Rutas no RESTful
Inline templates
Inline templates y templates estándar
etc.
La solución
La solución (no existe una única solución) Mi
Buenas Prácticas
* Definir una estructura de directorios
* ¿Cómo vamos a manejar los controllers?
* ORM (¿Necesitamos ORM?)
* Elegir una base de datos
* Elegir un Test framework
¿Classic o Modular?
* Configuración por defecto
* Configurar los diferentes entornos
* Elegir un template engine
== Application Template
Pero esto todavía no es un framework
* Tasks
* Autoload
Recordar:
Sinatra es flexible
Rack
Seamos inteligentes y usemos esto en nuestro favor
¿Preguntas?
¡Gracias!