<pre>Author/s : Bruce Tate Publisher : The Pragmatic Programmers Category :Other Review by : Marc Peabody Rating : 10 horseshoes</pre> I've been skeptical yet curious about Ruby. There are so many darn Java frameworks out there and I needed some justification to learn Ruby instead of yet another Java framework. Hey, I kinda have a life and I value my time.
This book doesn't teach Ruby programming but it might convince you to learn it. The cover reads, "Things Every Manager Should Know" yet you don't have to be a manager to appreciate Bruce's insights. Expect no syntax - this is a higher level blueprint for the revolution.
Bruce Tate reviews, without quibble, the dark sides of Java and what can cause the language itself to be the bottleneck of your team's velocity. You then discover what types of projects and work environments best cater to a Ruby pilot project. Bruce fairly weighs the risks and benefits for a variety of scenarios and even delves into how to put together an awesome Ruby team.
From Java to Ruby was so enjoyable a read, I finished it in two days. Pick up a copy but be warned: expect your colleagues to ask, "Hey, can I read that when you're done?"
I don't agree with the position of Bruce about the comparison between manufacturing process and software process, oriented to get a quickly software delivery process, because in manufacturing you can make more products with less quality to sold less expensive and then make changes in the production process to get better quality to you product in order to get more consumer coverage and become more competitive. In software there couldn�t be used if you aren�t produce a massive application, for example in a Enterprise Information System the quality of your delivers are very important, and you need to understand the business logic in order to make a good usefully application for the users, the advantage could be taken if you make a good division of requirements in order to separate the effective business needs (all the services that the user need to-do no matter how) and the comfortable business needs (how the user can do something with more friendly process), between this two kind of requirements you can fill all the system requirements in order to identify what requirements are build in the first iterations of the process. The previous process is very different like a manufacturing process and need to understand the business logic and organize this in order to make a delivery, quality and performance Information System Application there is the reason why in manufacturing you don�t have a architect of production or something similar.