From 734b15dab959cb19f316428d4dc7b0e085760f89 Mon Sep 17 00:00:00 2001 From: JoseĢ Mota Date: Tue, 26 Jun 2012 08:21:31 +0100 Subject: New post: Extract business. --- _posts/2012-06-26-extract-your-business.markdown | 56 ++++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 _posts/2012-06-26-extract-your-business.markdown (limited to '_posts') 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. -- cgit v1.2.3-54-g00ecf