New post: Extract business.

1 files changed, 56 insertions, 0 deletions

diff --git a/_posts/2012-06-26-extract-your-business.markdown b/_posts/2012-06-26-extract-your-business.markdown
new file mode 100644
index 0000000..7c3da32
--- /dev/null
+++ b/_posts/2012-06-26-extract-your-business.markdown
@@ -0,0 +1,56 @@
+---
+layout: post
+title: Extract your business
+tags: [ development ]
+published: true
+---
+
+I've come to realize one big factor to consider when building Ruby apps.
+
+I've given a [talk at
+AgilePT](http://2012.agilept.org/program/invited-talks#toc-anchor-4034-10) on
+how agile is Ruby on Rails. I should know better than just encouraging
+businesses to adopt Ruby and Rails into their development. There's one thing
+that so many people face and most of the time evangelists discard:
+_regression_.
+
+I love working with Rails, it's a living organism. It's in its nature to
+survive, it won't stale like most software tends to at some point. However,
+because of that it's important to consider its volatility. _How is a product
+supposed to follow the ever so changing nature of the framework_?
+
+Why isn't your business a gem of its own?
+-----------------------------------------
+
+The business of a product is as important as the tools you use, perhaps even
+more important. As product owners we ought to care more on how our business
+logic is managed. The good thing about Rails is that it's so well organized and
+its conventions are so straightforward that it's not really that hard to set
+your logic apart from the framework.
+
+If you care enough about your product and also you constantly strive for 
+innovation and early adoption, then it's best to protect your software from the
+framework, not just because Rails is often patched and upgraded with new
+features over time but also because it allows you to change more easily.
+
+It's totally acceptable to acknowledge you might not be into Rails anymore, or
+perhaps there's a feature in the framework you're not so fond of and you wish
+to defy standards by adopting a different solution for a certain problem:
+
+* You might not be into SQL anymore and you want to switch to Couch, Mongo or
+  any other database;
+* Perhaps you have a different way of persisting data like Hibernate (if you're
+  using JRuby);
+* You want to improve performance by tweaking the frameworks' defaults.
+* How about extracting your app into a JSON API and go heavy on Javascript?.
+
+Change is always imminent. I learned that the hard way and Ruby now gives me
+confidence upon change. TDD is an awesome leader that _accepts change as a
+reality and no longer a challenge_. Also, it provides guidelines to better app
+design and that increases maintainability.
+
+The framework should only support common tasks, that's why it's called a
+framework. All the MVC paradigm, boilerplate, persistence, helpers, templating
+and email can be handled by Rails, _it can be safely upgraded without
+compromising your business logic_. It will be my personal goal to improve on
+this as I have a lot to go through yet.